陈小严先把结论放在前面：绝大多数 MySQL 性能问题，根子都出在索引设计上。这不是夸张，从我接手过的线上案例来看，十次慢查询里至少有七八次，explain 一出来，要么是全表扫描，要么是索引建了但没用上。这篇文章不打算讲那些特别虚的“理论大全”，而是以我实际排查和优化过的经验为主线，把索引优化从“该怎么想”到“具体怎么干”完整梳理一遍。不管你是刚接触数据库的新人，还是被线上慢查询折磨过的老手，这篇文章应该都能给你一些可以直接落地的思路。
文章会围绕这样一条主线展开：先搞明白索引到底在解决什么问题，再学会判断哪些场景真正需要优化，接着是实际动手建索引、调 SQL 时那些容易踩的坑，最后是问题排查时怎么一步步定位到根因。每一部分都会尽量说清楚“为什么这么做”，而不是只丢给你一堆结论。
1. 索引优化的本质：先搞清楚索引到底在解决什么问题
1.1 索引不是“加速器”，而是一种查找结构
很多人对索引的理解，就是“加了索引查询就变快”。这句话方向对，但容易让人忽略一个关键点：索引不是玄学，它本质上是一种数据结构，目的是减少数据库扫描的数据量。
MySQL 里最常见的 InnoDB 引擎，索引用的是 B+ 树。为什么要用 B+ 树？你可以把数据库表想象成一本书，没有索引的时候，你想找某个词，就只能从第一页翻到最后一页，这叫全表扫描。有索引就相当于书最后附了一个“关键词+页码”的目录，你查目录定位到页码，直接翻过去就行。
B+ 树的厉害之处在于，它的每个节点可以存储很多个键值，树的高度通常只有 2 到 4 层。也就是说，哪怕表里有几千万行数据，你通过索引查找一条记录，往往只需要做 3 到 4 次磁盘 I/O。而全表扫描，可能需要读几千个数据页。这个差距，在小数据量时感觉不明显，一旦数据量上了百万级，就是几十毫秒和几十秒的差别。
但这里有一个常见的误解：索引并不是“建得越多越好”。每建一个索引，写入数据时就要多维护一份 B+ 树结构，插入、更新、删除的性能都会受影响。所以索引优化的核心，不是“把所有字段都加上索引”，而是“在合适的查询场景下，用最少的索引覆盖最多的查询需求”。
1.2 什么时候需要优化索引：慢查询的三种典型迹象
在实际工作中，判断要不要做索引优化，我一般看三个信号。
第一个信号是慢查询日志里出现了执行时间超过阈值（比如 1 秒）的 SQL。这种情况最直接，说明这条 SQL 在当前数据量下已经跑不动了。先用 EXPLAIN 看一下执行计划，如果 type 列是 ALL（全表扫描），或者 rows 列估算扫描行数特别大，那基本就是索引的问题。
第二个信号是数据库 CPU 使用率居高不下，但并发量其实并不高。这时候有可能是某些 SQL 在做大量磁盘 I/O，导致 CPU 大部分时间在等待 I/O 完成。这种“CPU 高但业务量不大”的诡异现象，往往也是索引缺失导致的。
第三个信号比较隐蔽，是随着数据量增长，接口响应时间出现“阶梯式”上升。比如数据量在 50 万时接口只要 50ms，到了 100 万时突然变成 500ms，这种非线性增长通常意味着数据量已经突破了某个索引结构的承载阈值，比如联合索引的区分度下降、或者原本的索引选择已经不再适合当前的查询模式。
1.3 索引优化的边界：不是所有 SQL 都靠索引解决
有一点必须提前说明，索引不是万能的。如果你的 SQL 里写了 LIKE '%关键词%' 这种前置模糊匹配，或者对字段做了函数运算（比如 WHERE YEAR(create_time) = 2024），那就算建了索引，MySQL 也会因为无法对计算结果直接匹配索引，而放弃使用索引。这种情况下，更合理的做法是调整查询写法，或者引入额外的搜索方案（比如 ES），而不是死磕索引。
另外，索引优化解决的是“查询”问题，不解决“写”问题。如果你的系统瓶颈在于写入冲突、锁等待，那就算索引建得再好，也无济于事。所以做优化之前，先定位好瓶颈到底在哪一层。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 索引设计的核心细节：建索引前必须想清楚的几件事
2.1 区分度：索引列的选择标准
建索引之前，你要先问自己一个问题：这个字段的值，能不能有效区分出不同的数据行？这个指标在 MySQL 里叫“区分度”（Cardinality），意思是索引列中不重复值的数量。
为什么区分度这么重要？因为索引查找的本质，是通过 B+ 树快速缩小范围。如果一列的值只有几种（比如 status 字段只有“待支付”“已支付”“已取消”三种值），那即使建了索引，MySQL 通过索引定位到的仍然是一大片数据，最终还是得一个一个回表去看。这种情况下，优化器可能会觉得“走索引还不如直接全表扫描快”，于是干脆不用索引。
那怎么判断区分度够不够？我的经验是，对于单列索引，如果这列的不重复值数量除以总行数，比值低于 20% 左右，就要谨慎考虑是否值得建索引。当然这个比例不是绝对的，比如一些枚举字段虽然区分度低，但如果配合其他条件组合查询，仍然可能有价值。
用一个实际例子来说明，假设有一个用户订单表，里面有 user_id、status、create_time 三个字段。如果查询是“查某个用户的所有待支付订单”，那 user_id 的区分度很高（每个用户对应的订单数相对较少），而 status 的区分度很低。这时候建联合索引 (user_id, status)，就能先用 user_id 精确定位到某用户的订单，再在结果内筛选 status，效率会好很多。
2.2 联合索引的最左前缀原则
联合索引可能是索引优化里最实用、也最容易被用错的知识点。MySQL 的联合索引遵循“最左前缀原则”：一个联合索引 (a, b, c)，实际上相当于建了 (a)、(a, b)、(a, b, c) 三个索引。
这意味着，如果查询条件里只包含 b 和 c，不包含 a，那这个联合索引是用不上的。反过来，如果你查的是“只带 a 条件”或者“带 a 和 b 条件”，那就都能命中索引。
这个特性在索引设计时非常关键。你要根据业务查询的实际情况，把最常作为查询条件的字段放在最左边，这样才能最大化利用联合索引。举个例子，一个订单表的常用查询有四种：
- 按
user_id查 - 按
user_id加status查 - 按
user_id加create_time查 - 按
create_time查
在这种场景下，建 (user_id, create_time) 联合索引，比分别建 user_id 单独索引和 create_time 单独索引更合理。因为 (user_id, create_time) 既能覆盖前三种查询，又因为 user_id 在左边而不会失效。而单独的 create_time 索引，只有在第四种查询时才能用上，覆盖场景太窄。
2.3 回表与覆盖索引：索引优化里的“性价比之王”
关于索引，很多人忽略了一个概念——回表。当你通过索引找到了符合条件的记录后，如果索引里没有包含查询需要的所有字段，MySQL 就必须拿着得到的主键值，再到主键索引（聚簇索引）里查找完整的数据行，这个过程就是回表。回表意味着额外的磁盘 I/O。
那有没有办法避免回表？答案就是覆盖索引。如果查询需要的所有字段都包含在索引本身中，那 MySQL 在索引的 B+ 树上就能直接拿到全部数据，不用再回表了。
这里我特别想强调一个真实案例：之前帮一个电商客户优化订单查询，原始 SQL 是这样的：
sql复制SELECT order_id, order_amount, status