说真的，我见过太多开发者在 MySQL 调优上踩坑。刚入行那会儿，我也干过这种蠢事：一遇到查询慢，二话不说就往 SQL 里塞索引，结果索引堆得比山还高，写操作慢得像蜗牛爬。后来跟一个 DBA 老大哥喝茶，他一句话点醒了我：“调优不是往数据库里贴膏药，你得先看懂它在干什么。”从那以后，我开始认真看慢查询日志、分析执行计划，才慢慢摸到门道。MySQL 调优这事儿，说白了就是一场跟数据打交道的心理战——你得知道它怎么想，才能对症下药。
先说索引，这是调优的必修课，也是最容易翻车的地方。很多人觉得索引越多越好，恨不得每列都建一个，结果查询快是快了，但每次插入、更新数据，MySQL 都得吭哧吭哧维护所有索引，性能反而崩了。我有个朋友在电商公司，订单表建了十几个索引，双十一那晚数据库直接卡死，发现 80% 的索引根本没用上。正确的做法是：先看你的查询模式，比如 WHERE 子句里常用的字段、ORDER BY 和 GROUP BY 涉及的列，再针对性建索引。复合索引更讲究“最左前缀原则”，假设你建了 (a, b, c) 的索引，查询条件里必须包含 a 才能用到，否则索引白建。别小看这个细节，很多新手就是栽在这儿。
索引之外，SQL 语句本身也藏着不少猫腻。我见过最典型的案例是：一个公司内部系统的报表查询，跑一次要半分钟，业务方天天骂。后来我一看 SQL，原来是 SELECT * 把整表数据都拉出来，再在应用层做分页。改成分页查询加覆盖索引后，直接从 30 秒降到 0.3 秒。还有那些用了 NOT IN、LIKE '%xxx%' 的语句，基本都会全表扫描，建再多索引也没用。别迷信 ORM 框架，它生成的 SQL 有时蠢得让人想哭。写 SQL 前，养成用 EXPLAIN 看执行计划的习惯，检查 type 列是不是 range 或 ref；如果看到 ALL 或 index，那基本就需要优化了。
说完查询，再说表结构和数据类型的坑。我经常看到有人用 VARCHAR(255) 存 IP 地址，或者用 TEXT 存几十个字符的备注，这简直是拿大炮打蚊子。MySQL 按 B+ 树组织数据，字段类型越宽，每页能放的行数越少，查询时需要读取的页就越多。比如用 INT 代替 VARCHAR 存状态码，用 DATETIME 代替 VARCHAR 存时间戳，不仅节省空间，还能利用索引排序。尽量使用 NOT NULL 约束，因为 NULL 值在索引中处理更复杂，还会占用额外存储。表设计时，适度的反范式化有时比严格的三范式更实用——比如把用户昵称冗余到订单表里，就能避免频繁的 JOIN。
说到配置参数，很多人觉得这是 DBA 的事儿，其实不然。MySQL 默认配置是为 8 GB 内存的虚拟机准备的，你用 128 GB 的服务器跑默认配置，等于开着法拉利挂一档。最常用的参数是 innodbbufferpoolsize，建议设为机器物理内存的 70%–80%，但别超过 128 GB，否则会有内存寻址开销。另一个是 querycachesize，这在 MySQL 8.0 已经废弃，但很多老项目还在用。它看似能缓存查询结果，却在表有更新时让整个缓存失效，并发高时反而成负担。我建议直接关闭 querycache，改用应用层的 Redis 或 Memcached 替代。
硬件层面同样不能忽视，尤其是磁盘 I/O。MySQL 的 InnoDB 引擎依赖磁盘读写，如果用的是机械硬盘，IOPS（每秒读写次数）就是瓶颈。我曾帮一个游戏公司优化数据库，他们用 SATA 硬盘跑高并发订单表，查询延迟动不动就上秒。换成 NVMe SSD 后，同样的 SQL 语句，响应时间直接从 800 ms 降到 20 ms。更简单的办法是调整日志写入策略：把 innodbflushlogattrxcommit 设为 2，能大幅提升写入性能，代价是崩溃时可能丢失 1 秒的数据。对于非金融类业务，这风险是可控的。
想说，调优不是一锤子买卖。我见过太多团队上线前猛调一通，上线后就把监控扔一边。MySQL 的慢查询日志、Performance Schema、系统变量状态都是宝贵的“体检报告”。比如可以定期检查 Handlerreadrndnext 的值，如果它远大于总行数，说明索引没起作用。还有 Innodbrowslockcurrentwaits，这个值一旦飙升，说明并发锁冲突严重，需要考虑优化事务隔离级别或拆表。调优是个持续迭代的过程，今天查得快的 SQL，下一月数据量翻倍可能就崩了。所以，别怕麻烦，把监控工具跑起来，让数据说话。
