数据库优化实战指南

徒弟啊，今天咱们聊聊数据库优化这件事。很多刚入行的开发者总觉得数据库就是个存数据的地方，等系统跑起来了才发现查询慢得像蜗牛，这时候才想起来优化，往往已经晚了。其实数据库优化应该从写第一行代码就开始考虑。

先说查询优化，这是最常见的问题。你写 SQL 的时候别图省事随便写，每条查询都要想想执行计划。比如你有个用户表，经常按用户名查询，那就得给 username 字段加索引。用 EXPLAIN 命令看看 MySQL 怎么执行你的查询，要是看到 type 列显示 ALL，说明在全表扫描，赶紧加索引。记住索引不是越多越好，写操作多的表索引太多反而拖慢速度。

查询语句本身也有讲究。能用 WHERE 就别用 HAVING，因为 HAVING 是在分组后过滤，效率低。SELECT 的时候别用星号，只取需要的字段，减少数据传输量。多表 JOIN 的时候，确保关联字段都有索引，而且小表驱动大表。分页查询用 LIMIT 的时候，如果偏移量很大，可以考虑用 ID 范围代替，比如 WHERE id > 10000 LIMIT 20 比 LIMIT 10000, 20 快得多。

再说说数据库设计。表结构合理了，后面省很多事。字段类型能小就别用大的，比如能存 TINYINT 就别用 INT。varchar 长度给够但别浪费，文本特别长的考虑用 TEXT 类型单独存。范式要遵守，但也别过度，有时候适当冗余能减少 JOIN 提升性能。

备份恢复是保命的东西，千万别忽视。最简单的备份用 mysqldump 命令，比如 mysqldump -u root -p database_name > backup.sql 就能导出整个数据库。生产环境建议加上 single-transaction 参数，避免锁表影响业务。定时备份用 crontab 设置，每天凌晨执行一次，备份文件保留最近七天的就行。

恢复数据的时候先建空数据库，然后用 mysql -u root -p database_name < backup.sql 导入。导入大文件可能很慢，可以临时调大 max_allowed_packet 参数。要是误删了数据，从备份恢复是最稳妥的，所以备份一定要定期测试，别等到用的时候才发现备份文件是坏的。

性能监控不能少。开启慢查询日志，把执行超过 1 秒的查询都记下来，定期分析这些慢 SQL。用 SHOW PROCESSLIST 看看当前有没有锁表或者长时间运行的查询。生产环境装个监控工具，比如 Prometheus 加 Grafana，实时看数据库状态，有问题提前发现。

最后记住一点，优化是个持续的过程。上线前做压力测试，用 sysbench 模拟真实负载，看看数据库能不能扛住。上线后持续关注性能指标，发现问题及时调整。数据库优化没有银弹，得结合具体业务场景来，多实践多总结，慢慢就有感觉了。