数据库优化这件事，说难也难，说简单也简单。我带过不少徒弟，发现大家最容易栽跟头的地方，往往不是技术有多深，而是基础没打牢。今天咱们就从最实用的角度，聊聊 MySQL 数据库优化的那些事儿。

先说查询优化，这是见效最快的。很多新手写 SQL 语句，怎么方便怎么来，结果数据量一上来就卡壳。我有个徒弟做的系统，刚开始几百条数据时跑得飞快，后来数据到了几万条，页面加载要十几秒。我一看他的查询，好家伙，全是全表扫描，连索引都没有。

索引这东西，就像字典的目录。你查一个字，如果从第一页翻到最后一页，那得找半天。但要是查目录，一下就定位到了。给常用的查询字段加上索引，性能能提升几十倍甚至上百倍。不过索引也不是越多越好，太多会影响写入速度，得把握平衡。

查询语句本身也有讲究。能用 SELECT 指定字段的，就别用 SELECT *。能加 WHERE 条件限制范围的，就别全表查。能用 JOIN 一次查出来的，就别在程序里循环查询。这些都是老生常谈，但真能做到位的不多。

再说表结构设计，这个影响更长远。我见过一个电商系统，订单表就一张，所有类型的订单都往里塞。刚开始还行，后来数据量大了，查询慢得要命。后来按订单类型分表，性能立马就上去了。

范式理论要遵循，但也不能死板。有时候适当的冗余能提升性能。比如订单表里存一份用户名称，虽然违反了第三范式，但查询时就不用 JOIN 用户表了，反而更快。关键是要根据实际场景权衡。

备份恢复是最后一道防线。我见过太多次数据丢失的悲剧，都是因为备份没做好。mysqldump 是最常用的工具，简单可靠。数据量大的话可以用 XtraBackup，支持热备份。备份文件要定期测试恢复，不然真到用时发现备份是坏的，那就晚了。

备份策略也有讲究。我推荐每天增量备份，每周全量备份。备份文件要存到不同地方，本地一份，云端一份。重要数据甚至可以三份，防止意外。

性能监控不能少。我习惯用 MySQL 的慢查询日志，把执行时间超过一秒的查询都记下来，定期分析优化。Performance Schema 也能提供很多有用信息，比如哪些表访问最频繁，哪些锁等待时间最长。

数据库优化是个持续的过程。刚开始可能效果不明显，但坚持下来，系统性能会越来越稳定。关键是要养成好习惯，写查询时多想想执行计划，设计表时多考虑扩展性，日常运维多关注监控数据。

记住，优化不是为了炫技，是为了解决实际问题。别为了优化而优化，找到瓶颈再下手，往往事半功倍。