数据库一打开，慢查询、锁冲突、磁盘占满，几乎每个开发者都碰过。别急，这些症状背后往往有几个“常犯的错误”。把它们挑出来，针对性下手，性能提升往往比买更大的机器来得快。下面把常见的几条优化手段拆开聊，看看哪些能直接落地。
索引是查询的加速器，却也是最容易被滥用的工具。很多人把每个字段都建成普通索引，以为这样查询一定快，结果写入成本翻倍，甚至出现全表扫描。真正需要索引的场景是：过滤条件里出现了等值或范围查询，且返回的行数远小于全表。复合索引要遵循最左前缀原则，最左边的列必须是过滤最频繁的那一个。还有一种情况，查询只需要排序而不返回列时，单独给排序列建索引可以让 MySQL 直接使用索引顺序，省掉一次文件排序。别忘了定期检查慢查询日志，看看哪些查询根本没走索引，针对性加或删。
表结构设计决定了磁盘占用和 I/O 量。把大文本、图片等二进制数据直接塞进 VARCHAR 或 BLOB，往往导致行太宽，扫描时必须把整行读进内存。把这些大字段拆成独立的表，采用一对多的方式存储，查询普通业务时只需要读轻量级的主表。再说字段类型，别为了“一点点灵活”把年龄设成 VARCHAR，改成 INT，存储空间立马省下几倍，索引也更紧凑。还有一个细节，尽量把经常一起查询的列放在同一行里，减少磁盘碎片，提高缓存命中率。
查询本身也能做很多“自我调教”。WHERE 子句里尽量避免函数或计算，例如 会把索引踢出局部，改成 才能命中。JOIN 语句里，先把大表过滤后再和小表关联，避免把小表的全部记录拉进来。子查询有时会被 MySQL 当成临时表处理，改写成关联查询或使用 EXISTS/NOT EXISTS，往往可以让优化器选出更好的执行计划。还有一个常被忽视的技巧：把 LIMIT 放在需要的地方，尤其是分页场景，配合合适的索引，MySQL 只会读取前几页的数据，而不是全表扫完再截取。
缓存是数据库之外的加速层。很多业务把热点数据直接放在 Redis、Memcached，查询时先查缓存，命中就直接返回，未命中再落库。这里的关键是缓存粒度和失效策略。把整条记录当成一个键值缓存，更新时记得同步或使用延迟双删，防止脏读。还有一种做法，把经常聚合的统计结果缓存下来，定时刷新或在写入时主动更新，这样可以把原本需要几秒的 GROUP BY 变成一次内存读取。缓存虽快，但别把所有数据都塞进去，成本会爆炸，选对热点才是王道。
事务和锁的管理也会直接拖慢响应。长事务会持有行锁或表锁，导致其他会话排队。常见的误区是把一大堆业务逻辑放进同一个事务，结果事务几分钟都没提交。拆分事务、把只读的操作放在事务之外、使用更细粒度的锁（比如行锁代替表锁），都能让并发度提升。还有一种情况是使用了默认的 REPEATABLE READ 隔离级别，导致幻读和锁竞争，改成 READ COMMITTED 在保证数据一致性的前提下，锁的持有时间会更短。对一些不需要强一致性的场景，甚至可以考虑使用 READ UNCOMMITTED，速度提升肉眼可见。
硬件层面也不是万能的借口。磁盘 I/O 是 MySQL 的瓶颈之一，传统机械盘在高并发写入时会出现排队。换成 SSD 或者把日志文件、数据文件分别放在不同的磁盘上，能让读写并行。再说内存，InnoDB 的 buffer pool 越大，越能把热点数据常驻内存，减少磁盘读取。一般建议 buffer pool 至少占机器内存的 60%，但别把系统留的余地太少，导致交换频繁。CPU 核数多可以开启并行查询、并行复制，让主从同步更快。硬件升级固然能带来性能提升，但如果前面的索引、查询、事务都没有调好，买再贵的机器也只能跑慢。
把这些点一条条对照自己的项目，先从最容易实现的地方下手。打开慢查询日志，找出最耗时的几条，检查是否走了索引，是否用了函数。再审视一下表结构，看看有没有超宽列或不合适的字段类型。接着把热点查询搬到缓存，或者把大表拆分成主从。把长事务切短，调低锁的粒度。一步步推进，往往能把 5 秒的查询压到秒级，甚至更低。性能不是一次性工程，持续监控、定期回顾，才能让系统保持在健康的跑速上。
