聊到 MySQL 查询优化，很多人的第一反应就是“加索引”。这话没错，但就像炒菜只知道放盐一样，缺少了太多层次。我见过不少开发者，索引加了，查询仍然慢得像蜗牛爬，气得拍桌子骂数据库。其实，MySQL 查询优化就像给一辆老车调校发动机，你得摸透它的脾气，知道哪儿该拧螺丝、哪儿该换零件。今天咱们就把它掰开揉碎，聊聊怎么让 MySQL 跑得顺溜点，而不仅仅是加索引那点事儿。
先说索引本身，这东西确实是块宝，但得会用。比如你有个表存了 100 万条用户数据，查询 ，如果只在 age 上建索引，MySQL 会先扫一遍 age 索引，找出所有大于 30 的记录，然后再回表查 city，这中间可能要翻几十万行。更聪明的做法是建一个联合索引 ，这样索引直接过滤掉大部分数据，回表次数少得可怜。联合索引也有讲究，最左前缀原则你得懂：索引 ，查询里必须使用 a 才能生效，否则就白搭。我见过有人把性别这种区分度极低的字段放在联合索引最左边，结果索引几乎没效果，白白浪费磁盘空间。
再聊一个容易被忽略的坑：索引不一定越多越好。有些表建了七八个索引，每次写数据都要更新一堆索引树，磁盘 I/O 扛不住，并发高了直接卡死。更烦人的是，MySQL 优化器有时会选错索引。你明明觉得该走索引 A，它偏走全表扫描，或者走了个效率更低的索引 B。这时候别急着骂 MySQL，先检查统计信息是否过时。用 刷新一下，或者强制指定索引，例如 ，但别滥用，这只是临时拐杖。真正的问题往往是查询逻辑写得不够干净。
说到查询逻辑，很多慢查询的根源在于 SELECT 了太多无用的列。比如你只需要用户名和邮箱，却写了 ，MySQL 必须把整行数据捞出来，包括大文本或 BLOB 字段，这就像去超市买瓶水，却推了整个购物车，绕了整圈。正确的做法是只选需要的列，尽量使用覆盖索引——即索引里已经包含了你要的字段，这样连回表都省了。比如有个索引 ，查询 ，MySQL 直接从索引里拿数据，磁盘 I/O 少得可怜。
还有一类问题是查询条件写得不够聪明。比如 ，这种写法会让 MySQL 无法使用索引，因为函数改变了字段值。应该改写为 ，这样索引才能正常工作。类似的， 开头的通配符也会导致索引失效。如果必须使用，考虑全文索引或搜索引擎，别死磕 MySQL。再说 和 的选择，很多人觉得 慢，其实 MySQL 5.6 之后对 已经做了优化，子查询数据量小的时候并不一定比 差，关键还是看具体数据分布，别盲目下结论。
表结构设计也是优化的关键，很多人只盯着查询，忘了表本身可能就有问题。比如字段类型选得太大，明明存年龄，用 TINYINT 就够了，却用了 INT，每个字段多占 3 个字节，1000 万行就多出 30 MB，索引也跟着膨胀。大文本字段不要直接塞进主表，拆成子表或使用 ES 存储，主表查询时会轻装上阵。更关键的是，分表分库需要提前规划。单表数据量超过几千万行，再好的索引也扛不住，因为 B+ 树层级加深，磁盘随机 I/O 暴涨。这时可以考虑按时间或用户 ID 分表，或使用 ShardingSphere 等中间件。但分表不是银弹，跨表查询、聚合计算会变得复杂，需要权衡业务场景。
聊聊慢查询日志和 EXPLAIN 分析。这两个工具是调优的“眼睛”。打开慢查询日志，设置 为 1 秒，然后定期扫一遍，找出拖后腿的 SQL。再用 看执行计划，关注 字段，从 system、const、ref、range、index 到 ALL，效率依次下降。如果看到 ，说明是全表扫描，必须赶紧优化。还要留意 和 ，比如 表示排序没走索引， 表示创建了临时表，都是性能炸弹。但别只看数字， 显示扫描 10 万行，实际只返回 100 条时，可以考虑增加索引或调整查询顺序。
说到底，MySQL 查询优化不是玄学，而是一套方法论：先了解数据分布，再设计合理的索引，接着优化查询逻辑，检查表结构和配置。每一步都要动手实验，别光看文档。我见过有人把查询时间从 20 秒降到 0.1 秒，只因为把 换成了 。也见过有人折腾半天，发现是服务器内存太小，缓冲池根本装不满。所以，别迷信某个技巧，多观察、多测试，MySQL 会老老实实告诉你哪里不舒服。优化这事，跟谈恋爱一样，得用心听它的声音。
