从慢SQL到索引优化：MySQL查询性能排查实战指南

1. 一条慢SQL逼我重新认识索引：先说结论再拆原理

先讲个真实的场景。前阵子帮朋友看一个线上问题，一张订单表大概500万行，列表页查询加了好几个条件，结果页面加载要4秒多。当时的SQL长这样：

sql复制SELECT order_id, order_no, user_id, total_amount, status
FROM orders
WHERE user_id = 10086
  AND status = 1
  AND created_at > '2024-01-01'
ORDER BY created_at DESC
LIMIT 20;

字段倒不多，条件也看着正常，但就是慢。EXPLAIN 一看，type 是 ALL，也就是全表扫描，rows 估算出来460多万。当时我第一反应不是加索引，而是想先搞明白一个问题：MySQL到底是怎么找到这些数据的？

这条SQL之所以慢，本质上就是没走索引，MySQL只能把500万行从头到尾摸一遍，把符合条件的捡出来，再排序、分页。听起来就像你在一本500万页的书里找一个关键词，但没有目录，只能一页一页翻。

这个案例带出了MySQL学习里最核心的两个主题：查询和索引。尤其是索引，它直接决定了查询是秒回还是卡死。如果你现在正在学MySQL，或者工作中已经遇到慢查询但不知道从哪下手，这篇文章就是围绕这个场景写的。我会从一条SQL在MySQL内部怎么执行讲起，再到索引的底层结构、联合索引怎么设计、EXPLAIN怎么看、索引为什么会失效，最后用一个完整的排查案例把整套思路串起来。保证不是那种“索引能提速所以加索引”的空话，而是能直接用到你项目里的实操逻辑。

2. 一条SELECT在MySQL里到底经历了什么

很多初学者一上来就背索引的B+树结构，但对SQL的执行链路完全没有概念。结果就是：索引背得滚瓜烂熟，慢查询来了照样不知道从哪查起。所以我建议先把执行链路搞明白，后面所有索引知识都有地方安放。

2.1 从连接器到执行器的五个环节

你往MySQL发一条查询，它内部要经过这么几个环节：

第一步：连接器。 负责和客户端建立连接、获取权限、维持和管理连接。这里有个实际影响：如果你用root账号连接后改了权限，已经建立的连接是不会重新校验的，要等下次连接才生效。所以生产环境改权限后，别指望线上连接立刻生效。

第二步：分析器。 先做词法分析，把你这条SQL拆成一个个关键字，识别出SELECT、FROM、WHERE后面的内容；再做语法分析，判断SQL语法是否符合MySQL的规则。如果语法不对，这里就会直接报错：ERROR 1064 (42000): You have an error in your SQL syntax。所以“SQL写错了”基本都是在这个阶段被拦下来的。

第三步：优化器。 这是索引发挥价值的最关键环节。SQL经过分析器之后，MySQL的优化器会决定用哪条索引、以什么顺序关联表。举个例子：

sql复制SELECT * FROM t1 JOIN t2 ON t1.a = t2.a WHERE t1.b > 100;

如果t1和t2都有索引，优化器就要判断先查t1还是先查t2，哪个代价更小。优化器内部有一套基于统计信息的成本估算逻辑。统计信息不准的时候，优化器也会“看走眼”，选错索引。这个点后面会专门说到。

第四步：执行器。 优化器定好方案后，执行器开始调用存储引擎接口，一行一行或者一批一批地把数据读出来，然后做条件判断、排序、聚合等操作。你看到的慢查询日志，就是执行完这个阶段后记录下来的。

2.2 优化器是怎么决定走不走索引的

优化器决定是否使用索引，核心依据是“代价估计”。MySQL会估算两种方案的代价：全表扫描的代价，和走索引查询的代价。谁的代价小，就用谁。

这里有个很常见的坑：你以为加了索引就一定走索引？不一定。 如果优化器发现，走索引需要回表太多次，代价比全表扫描还高，它就会放弃索引。

比如说一张100万行的表，你在某个低区分度字段（比如gender，只有male和female两个值）上建了索引。查询WHERE gender = 'male'，结果预估要查出50万行，那优化器大概率就全表扫了。因为用二级索引查50万行，就意味着要回表50万次，每回表一次就是一次随机I/O，这个代价远高于顺序读全表。所以很多DBA常说“低区分度字段不要建索引”，本质就是这个原因——建了也白建，优化器根本不买账。

2.3 实操：用show命令看连接和执行状态

排查慢查询时，有几个命令非常常用，比直接看日志更快：

sql复制-- 查看当前所有连接的状态
SHOW FULL PROCESSLIST;

这个命令能让你看到每个连接当前在干什么。如果某个连接显示State是Sending data、Sorting result，而且Time很大，基本就能锁定是它拖慢了数据库。如果是Waiting for table metadata lock，说明有DDL操作在排队，可能是有人在线上执行了没带ALGORITHM=INPLACE的ALTER TABLE。

另外一个命令是查看优化器的开关和参数：

sql复制SHOW VARIABLES LIKE 'optimizer_switch';

里面能看到index_merge、mrr等优化开关是否开启。MRR（Multi-Range Read，多范围读）开启的情况下，二级索引回表会先把主键值排序，再做磁盘顺序读，能减少随机I/O。有些老版本或者特殊配置会把MRR关掉，如果你发现回表查询性能异常，可以检查这个开关。

3. 索引的底层到底是什么：目录之外还有更多门道

索引最常见的类比是“书的目录”。但说实话，这个类比只解释了索引“能加速查找”这一个特征，完全没有解释MySQL为什么选B+树而不是别的结构。这一节我用最直白的方式讲清楚。

3.1 为什么是B+树而不是哈希表、二叉树、B树

MySQL里其实有两种常见的索引数据结构：B+树索引和哈希索引（InnoDB的自适应哈希索引是自动管理的，手动建索引默认都是B+树）。但InnoDB的索引默认就是B+树。为什么？

先看哈希表。哈希索引的查找速度非常快，等值匹配（WHERE id = 5）在理想情况下是O(1)的复杂度。但问题在于，哈希索引不支持范围查询、不支持排序。你查WHERE id > 100，哈希表就懵了，因为它把每个键都打散到了不同的桶里，无法按顺序遍历。而SQL里范围查询和排序是家常便饭，所以哈希索引只能作为辅助存在（Memory引擎默认是哈希索引，但不适合做核心业务的持久化存储）。

再看二叉树。二叉树的高度和节点数有关，500万行数据的二叉树，树高大概23层，意味着最多要23次磁盘I/O才能找到目标节点。虽然不算多，但随着数据量增长，树越来越高，I/O次数越来越多，不可控。

CarlyB树。B树和B+树的区别在于：B树的每个节点都存储数据，B+树的非叶子节点只存索引不存数据，所有数据都挂在叶子节点上，并且叶子节点之间通过链表相连。这个差异带来了两个关键优势：

1. 非叶子节点只存索引，意味着每个节点能容纳更多索引项，树更矮，I/O更少。InnoDB的页大小默认16KB，一个非叶子节点能存上千个索引键，500万数据也就3到4层。
2. 叶子节点用链表串起来，天然支持范围查询和排序。查WHERE id BETWEEN 100 AND 200，只需要找到100这个位置，然后顺着链表往后读就行，不用回溯。B树要做中序遍历才能拿到范围结果，效率差不少。

3.2 聚簇索引、二级索引和回表

InnoDB的表就是按主键索引组织的，这个索引叫做聚簇索引（clustered index）。聚簇索引的叶子节点直接存整行数据。也就是说，你建了主键，整张表就是一棵以主键为序的B+树，数据本身就在这棵树里。

没有主键怎么办？InnoDB会选一个非空的唯一键作为主键，如果也没有，就生成一个隐藏的rowid作为主键。所以建表时最好显式指定主键，而且建议用自增整数或雪花ID，不要用随机UUID当主键。随机UUID导致插入时B+树频繁做页分裂，插入性能会明显下降。

二级索引（也叫非聚簇索引）不一样，它的叶子节点不是完整数据，而是主键值。你给user_id建了索引，那么这棵B+树的叶子节点存的就是user_id和对应的主键id。当你用WHERE user_id = 10086查询时，先在二级索引里找到主键id，再拿id回聚簇索引里查整行数据，这个动作叫回表。

回表是有代价的。所以我们设计索引时，会尽量用**覆盖索引（covering index）**来避免回表。比如：

sql复制CREATE INDEX idx_user_status ON orders(user_id, status);
SELECT user_id, status FROM orders WHERE user_id = 10086;

这条查询要的user_id和status都在这棵二级索引的叶子节点里，MySQL查到索引就可以直接返回，不需要回表。EXPLAIN里Extra字段会显示Using index，这就是覆盖索引的标志。

3.3 索引存储和哈希存储的适用场景对比

这里顺便把“索引存储”和“哈希存储”这对概念理一下。

索引存储（B+树）：适合绝大多数OLTP场景。查询稳定，支持范围、排序、前缀匹配。缺点是插入和删除如果主键不是顺序的，会伴随一定的页分裂开销。

哈希存储（哈希索引）：适合等值查询极端密集的场景，比如缓存表、会话表，WHERE key = ?这种。Memcached、Redis这类KV存储本质就是这个思路。在MySQL里，Memory引擎默认用的是哈希索引，InnoDB则提供了自适应哈希索引，在检测到某些等值查询非常频繁时，会在B+树之上自动构建一层哈希索引来加速，不需要人工干预。

所以我自己的经验是：别指望把MySQL当成KV缓存来用。如果你需要极高的等值查询吞吐，上Redis/Memcached更合适，MySQL的B+树再优化，和纯哈希结构比等值查询还是有一定差距。

4. 联合索引、最左前缀和索引下推：面试高频但很多人没用对

先说个常见误区，很多初学者以为联合索引就是把多个字段分别建索引。其实不对。联合索引是一个B+树，按多个字段的顺序依次排序。

4.1 联合索引的字段排列规则

假设我们建一个联合索引：

sql复制CREATE INDEX idx_user_status_created ON orders(user_id, status, created_at);

这个B+树先按user_id排序，user_id相同的记录再按status排序，user_id和status都一样时再按created_at排序。

这就引出最左前缀原则：查询条件里必须从联合索引的最左列开始连续匹配，索引才会生效。

• WHERE user_id = 10086 — 能用到索引
• WHERE user_id = 10086 AND status = 1 — 能用到索引
• WHERE user_id = 10086 AND status = 1 AND created_at > '2024-01-01' — 能用到索引
• WHERE status = 1 — 用不到索引，因为跳过了第一列
• WHERE created_at > '2024-01-01' — 用不到索引，同样跳过了前两列

这个规则背后是B+树的排序逻辑决定的。联合索引的排序是有先后依赖的，你直接查第二列，等于在一本先按姓氏再按名字排序的电话本里，只知道名字不知道姓氏，没法二分查找。

4.2 字段顺序该怎么定：区分度、高频、长度

这是索引设计里最实际的问题。我个人的习惯是按三条原则来排：

1. 区分度高的字段放前面。比如user_id的区分度远高于status，所以user_id放在第一列。这样B+树可以快速收敛到少量数据。
2. 高频等值条件优先。WHERE里经常出现的等值条件，比如user_id = ?，放在联合索引前面，有利于在最左前缀的约束下被充分利用。
3. 长度小的字段优先。字段类型越短，每个非叶子节点能存的索引键越多，树越矮，I/O越少。INT比VARCHAR(100)更适合放前面。

有一些场景可以打破这些原则。比如有一个字段是范围查询（>、<、BETWEEN），通常放在索引靠后的位置，因为范围查询一旦开始，后面的字段就无法用于精确定位了。这个后面会细说。

4.3 索引下推到底在优化什么

“索引下推”（Index Condition Pushdown，ICP）是MySQL 5.6引入的优化。理解它能帮你明白现在数据库的执行引擎有多聪明。

没有ICP时，二级索引查到主键ID之后，需要回表，回表后拿到完整数据再判断status等条件。

有ICP时，MySQL会把status等条件下推到存储引擎层，在读取二级索引的时候就一并判断掉。这个判断是在索引层面完成的，不需要回表就行，减少回表次数。

举个例子，idx_user_status(user_id, status)这条索引，执行：

sql复制SELECT * FROM orders WHERE user_id = 10086 AND status = 1;

没有ICP：把所有user_id = 10086的记录都回表，再在server层过滤status。
有ICP：在二级索引遍历时，发现status = 0的记录直接跳过，不回表。

EXPLAIN里Extra字段显示Using index condition，就说明ICP生效了。你不需要额外配置，它是默认开启的（optimizer_switch里的index_condition_pushdown=on）。但你要能看懂它，避免面试时问到了还不知道这词是什么意思。

4.4 实操：一个订单查询的联合索引设计实例

回到开头那个慢查询场景。当时的条件组合是：

sql复制WHERE user_id = ? AND status = ? AND created_at > ?
ORDER BY created_at DESC

我是这样一步一步设计联合索引的：

第一步，确认所有查询条件：user_id、status、created_at。三个字段。

第二步，区分度从高到低排：user_id区分度最高，放第一位；status区分度低，但它是等值条件且高频，放第二位；created_at是范围条件，放最后。

第三步，ORDER BY created_at DESC其实不用额外处理，因为索引已经按created_at排序（在user_id和status相同的前提下），MySQL可以顺着索引逆序扫。

于是建了：

sql复制CREATE INDEX idx_user_status_created ON orders(user_id, status, created_at);

建完之后同样的SQL，EXPLAIN的结果是type = ref，rows降到了几百行，接口从4秒多降到了几十毫秒。这就是索引设计正确与否的差别。

5. EXPLAIN是我见过最被低估的优化工具

很多初学者遇到SQL慢，第一反应是“加索引”“改SQL”，但不先看执行计划。这就像生病不检查直接开药，可能有效，但大概率在碰运气。EXPLAIN就是MySQL的CT扫描仪，能把一条SQL实际怎么执行看个通透。

5.1 EXPLAIN关键字段逐个讲

拿刚才那条SQL做演示：

sql复制EXPLAIN SELECT order_id, order_no, user_id, total_amount, status
FROM orders
WHERE user_id = 10086
  AND status = 1
  AND created_at > '2024-01-01'
ORDER BY created_at DESC
LIMIT 20;

输出结果里，关键字段有这些：

先说type。ALL就是全表扫描，最差；index是遍历了整棵索引树，虽然比全表稍微好一点，但如果索引覆盖不了所有字段，还是会回表，性能依然差；range是索引范围扫描，比如>、<、BETWEEN、IN，这已经不错了；ref是等值匹配，命中普通二级索引，常见且健康；eq_ref是主键或唯一索引等值匹配，多见于JOIN连接；const和system是极值，主键查单条。

再讲key_len。这个字段很多人忽略，但对联合索引来说极其重要。它告诉你当前这次查询实际用到了联合索引的多少字段。比如idx_user_status_created(user_id, status, created_at)：

• key_len只等于user_id的长度（比如4字节），说明只用到了第一列。
• 等于user_id加status的长度，说明用到了前两列。
• 等于三列长度之和，说明三列都用上了。

key_len的计算公式大致是：字段自身的字节数，VARCHAR还要加变长指针长度（通常2字节），如果是utf8mb4，一个字符占4字节，VARCHAR(100)就是400字节加上变长指针2字节再加NULL标记（如果允许NULL再加1字节）。看key_len能帮你判断联合索引是不是真的“用满”了。

5.2 最让DBA头疼的Using filesort

Extra字段里有Using filesort的时候，意味着MySQL需要额外做一次排序操作。注意“filesort”不是文件排序，它可能在内存里做也可能在磁盘上做，但无论如何都是额外开销。常见触发场景是：

sql复制SELECT * FROM orders WHERE user_id = 10086 ORDER BY created_at DESC;

如果你只建了idx_user_status(user_id, status)，ORDER BY created_at列不在索引里，MySQL需要把结果集捞出来后单独排序——这就是Using filesort。而如果你的索引是idx_user_status_created(user_id, status, created_at)，排序列已经有序，就不需要额外排序，Extra里不会出现Using filesort。

这里有个细节：范围条件搭配ORDER BY时，索引排序也可能失效。比如：

sql复制SELECT * FROM orders WHERE user_id = 10086 AND created_at > '2024-01-01' ORDER BY created_at DESC;

如果索引是idx_user_created(user_id, created_at)，范围查询之后created_at本来就是有序的，可以直接倒序返回。但如果范围条件跳过索引里的排序字段，或者SELECT的字段不在索引里需要回表，顺序可能就被打乱了。

5.3 实操：一条SQL的EXPLAIN前后对比

优化前：

code复制+----+-------------+--------+------------+------+---------------+------+---------+------+---------+----------+------------------+
| id | select_type | table  | partitions | type | possible_keys | key  | key_len | ref  | rows    | filtered | Extra            |
+----+-------------+--------+------------+------+---------------+------+---------+------+---------+----------+------------------+
|  1 | SIMPLE      | orders | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 4692960 |    1.23  | Using where; Using filesort |
+----+-------------+--------+------------+------+---------------+------+---------+------+---------+----------+------------------+

可以看出：全表扫描、没走任何索引、还要额外排序，rows高达460多万，这是灾难级的执行计划。

优化后，建上了联合索引，再看：

code复制+----+-------------+--------+------------+------+---------------+------------------------+---------+-------+------+----------+-----------------------+
| id | select_type | table  | partitions | type | possible_keys | key                    | key_len | ref   | rows | filtered | Extra                 |
+----+-------------+--------+------------+------+---------------+------------------------+---------+-------+------+----------+-----------------------+
|  1 | SIMPLE      | orders | NULL       | ref  | idx_user_status_created | idx_user_status_created | 8       | const,const | 1050 |    3.55  | Using index condition |
+----+-------------+--------+------------+------+---------------+------------------------+---------+-------+------+----------+-----------------------+

三个关键变化：type从ALL变成了ref，rows从469万降到了1050，Extra里出现了Using index condition（ICP生效）。这就是一条慢SQL走索引前后的典型差距。

6. 索引失效的经典场景：我踩过的坑和排查思路

索引建好了，但查询还是慢，这种情况你没遇到算我输。索引“建了但没走”的原因有很多，这一节我把常见的场景逐一拆开讲清楚，每个都附上我能复现的案例。

6.1 前导模糊查询：为什么%放前面就会失效

sql复制SELECT * FROM users WHERE name LIKE '%张%';

这条查询不可能走name索引。为什么？还是回到B+树的结构。B+树的排序是从左到右按字符串顺序排的，比如'张三'排在某些位置，'张伟'在其后。如果LIKE是'张%'，MySQL知道要找以“张”开头的范围，可以顺着索引去搜。但'%张%'只要求中间包含“张”，MySQL没法确定范围的起点，它必须把索引里所有字符串都过一遍才知道哪些包含“张”。这时候优化器大概率选择全表扫描，因为走索引还要回表，代价可能更高。

解决办法：如果业务上必须做包含模糊查询，建议：

• 改用'张%'前缀匹配，这能走索引。
• 或者用全文索引（FULLTEXT）。
• 或者引入Elasticsearch这类全文检索组件，让MySQL专注结构化查询。

6.2 对索引列做了函数运算或隐式类型转换

这也是高频踩坑点。下面这两种写法都会让索引失效：

sql复制-- 对索引列用函数
SELECT * FROM users WHERE DATE(created_at) = '2024-01-01';

-- 隐式类型转换
SELECT * FROM users WHERE phone = 13800138000;

第一种，DATE(created_at)把created_at字段用函数包裹后，索引就失效了。因为索引里存的是原始值，不是DATE()之后的值，MySQL无法在索引上做比较，只能把每行的created_at都算一遍再过滤。改成范围查询就好了：

sql复制SELECT * FROM users 
WHERE created_at >= '2024-01-01' 
  AND created_at < '2024-01-02';

第二种，phone字段如果是VARCHAR类型，传了个整数，MySQL会隐式地把字段转换成数字来比较。一旦对字段做了类型转换，索引同样失效。正确做法是传字符串：

sql复制SELECT * FROM users WHERE phone = '13800138000';

判断有没有隐式转换的一个技巧：看EXPLAIN的rows是否异常大，或者key是不是NULL，同时结合SHOW WARNINGS看MySQL实际执行时把SQL改写成了什么样子。

6.3 OR条件和非等值判断的坑

sql复制SELECT * FROM orders WHERE user_id = 10086 OR status = 1;

user_id有索引，status也有索引，但OR连接时，MySQL如果选择分别用两个索引去查，再把结果合并（index_merge），在某些版本和统计信息下可能不这么做，而是直接全表扫。稳妥做法是把OR改写成UNION ALL：

sql复制SELECT * FROM orders WHERE user_id = 10086
UNION ALL
SELECT * FROM orders WHERE status = 1 AND user_id != 10086;

另外一个点是NULL判断。IS NULL在MySQL的索引上其实是可以走的（type=ref），但如果你用IS NOT NULL，优化器可能觉得扫全表更划算，尤其是表里绝大多数记录这个字段都不为NULL的时候。

6.4 网上常说的find_in_set为什么走不了索引

热词里有个“findinset能走索引吗”。直接说答案：不能。FIND_IN_SET(target, str)函数的本意是判断target是否在逗号分隔的字符串列表str里。这个str是一个整体字段，MySQL没办法在B+树里对这个字段的“某个子串”建立有序索引。它本质上是对字段做函数运算，和WHERE FIND_IN_SET('A', tags)这种写法一旦出现，该字段索引就失效了。

我见过不少人在MySQL里用逗号分隔字符串存“标签”“分类”这类多值字段，然后查FIND_IN_SET，数据量小时没问题，数据量一大就是灾难。这类需求设计上就不该放在关系型数据库的单个字段里，应该拆成关联表，比如user_tag(user_id, tag_id)，然后给tag_id建索引。如果一定要用字符串存储，就引入全文索引或者搜索引擎。

6.5 优化器选错索引：统计信息和force index

有一种最让人无语的情况：索引建了，SQL也符合走索引的条件，但优化器就是不用，全表扫更快？还是它判断错了？

此时可以用ANALYZE TABLE刷新统计信息：

sql复制ANALYZE TABLE orders;

这个命令会重新统计表的行数、索引区分度等信息。表数据变化剧烈后统计信息可能过期，刷新之后优化器会重新评估。如果刷新后还是不走索引，可以用FORCE INDEX强制指定：

sql复制SELECT * FROM orders FORCE INDEX (idx_user_status_created)
WHERE user_id = 10086;

但我不建议一上来就FORCE INDEX。先分析为什么优化器不选这个索引，常见原因是这个索引区分度太低，优化器预估回表代价太高。如果确认是统计信息过期，刷新就行。如果确实是索引设计不合理，FORCE INDEX只是临时缓解，该重建索引还得重建。

7. 慢查询日志：线上排查的最终武器

前面讲了很多索引原理和执行计划，但线上环境更常见的问题是：库上一堆SQL，你根本不知道哪条慢。这时候就得靠慢查询日志来做全局扫描。

7.1 慢查询日志怎么开启和配置

MySQL的慢查询日志默认是关闭的。你可以通过下面两条命令动态开启（不需要重启实例，但重启后会失效，生产环境最好写到配置文件里）：

sql复制-- 开启慢查询日志
SET GLOBAL slow_query_log = ON;

-- 设置阈值，单位是秒，这里设置为1秒
SET GLOBAL long_query_time = 1;

-- 指定日志文件路径
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow-query.log';

注意一点：long_query_time的默认值是10秒，也就是说执行时间超过10秒的SQL才会被记录。对于大多数OLTP业务来讲，10秒太宽松了，1秒甚至0.5秒（500毫秒）更实用。低于1秒的SQL虽然不算“慢”，但频繁出现也可能意味着索引有问题。

在my.cnf或my.ini配置文件里加上对应的配置项，重启后永久生效：

ini复制[mysqld]
slow_query_log = ON
long_query_time = 1
slow_query_log_file = /var/log/mysql/slow-query.log

7.2 用mysqldumpslow快速定位TopSQL

慢查询日志如果积累久了会很大，直接打开看是不现实的。用mysqldumpslow工具可以直接按执行时间或者扫描行数排序：

bash复制# 按平均查询时间排序，只看前10条
mysqldumpslow -s at -t 10 /var/log/mysql/slow-query.log

-s at表示按平均查询时间排序，-t 10表示只显示前10条。这个工具还会把SQL里的具体参数值归一化成N，方便同类型SQL聚在一起统计。

在MySQL 8.0里，系统表performance_schema.events_statements_summary_by_digest也能查SQL维度的统计信息：

sql复制SELECT SCHEMA_NAME, DIGEST_TEXT, COUNT_STAR, AVG_TIMER_WAIT
FROM performance_schema.events_statements_summary_by_digest
ORDER BY AVG_TIMER_WAIT DESC
LIMIT 10;

这比翻日志更直观，因为它就是一张表，可以做各种维度分析和过滤。

7.3 慢查询排查的标准流程：六步法

踩了无数次坑之后，我摸索出了一条相对固定的排查链路，分享给你作参考：

第一步，抓慢SQL。 靠慢查询日志或performance_schema捞出真正拖慢数据库的SQL。别猜，先看数据。

第二步，看EXPLAIN。 对慢SQL执行EXPLAIN，重点看type、rows、Extra三个字段。如果type是ALL或者rows巨大，直接进入第三步；如果type是ref或range但rows还是很大，可能就是索引区分度不够或者SQL设计有问题。

第三步，看表结构和索引。 SHOW CREATE TABLE看建表语句，重点确认：字段类型是否合理、已有索引覆盖哪些列、有没有冗余索引。

第四步，分析SQL逻辑。 看WHERE条件里的字段是否和索引匹配，是否对索引列做了函数运算，是否有OR、NOT IN等特殊条件。这里经常发现SQL本身可以改写但一直没人管的写法。

第五步，小步快跑验证。 改动索引或SQL后，立刻EXPLAIN对比，再实测接口耗时。切忌一次改一堆东西，否则出了问题没法定位。

第六步，灰度上线和观测。 索引变更在低峰期执行，线上观察一段时间，看慢SQL是否减少，是否有新的慢SQL出现。加索引也不是纯收益，索引本身会占用空间，会增加插入、更新、删除的维护成本。

8. 一次实操复盘：从460万行全表扫描到几十毫秒

前面断断续续提到了开头的订单查询优化案例，这里我把完整过程串起来，也算是对整套知识的一次实战验收。

8.1 排查过程：从慢SQL日志到索引设计

当时拿到的问题就是：接口4秒多，DBA说数据库CPU偶尔飙高。我先开了慢查询日志，等了大概半小时，捞出来一条SQL，就是文章开头那条订单列表页查询。

用EXPLAIN看了一遍，确认是ALL类型，rows469万，Extra有Using filesort。再看表结构，发现表上有好几个单列索引，但都是idx_user_id、idx_status、idx_created_at这种独立索引，没有一个能同时覆盖三个条件的联合索引。

当时的优化思路是建一条联合索引覆盖查询条件，但要避免冗余。因为status区分度很低，单独为它建索引基本没意义，加在联合索引里就够了。最终决定：

sql复制ALTER TABLE orders 
ADD INDEX idx_user_status_created (user_id, status, created_at);

8.2 效果验证与结果数据

建索引后，再次执行：

sql复制EXPLAIN SELECT order_id, order_no, user_id, total_amount, status
FROM orders
WHERE user_id = 10086
  AND status = 1
  AND created_at > '2024-01-01'
ORDER BY created_at DESC
LIMIT 20;

结果对比：

额外的收益是：由于覆盖了排序字段，ORDER BY created_at DESC不再触发Using filesort，排序开销被消掉了。这里还要补充一个细节：同样的索引，如果status字段不参与查询，key_len就会变短，说明只用了联合索引的前缀部分。所以联合索引不是建了永远能完全用到，查询条件不同，利用率也不同。

8.3 这类索引只能解决当前SQL，不是万能药

说句泼冷水的话，这条联合索引只对当前SQL有效。如果业务方下次又加了一个WHERE shop_id = ?条件，这个索引可能又不够用了。所以索引设计不是一个“建一次”的动作，而是伴随业务SQL变化持续迭代的过程。

比较好的做法是每隔一段时间，把慢查询日志里的SQL拉出来做聚合分析，看有没有新的高频慢查询模式。这个动作建议做成巡检脚本或者定时任务，而不是等着用户投诉、CTO找你。

9. 最后分享一个关于索引维护的自查习惯

文章讲到这里，核心内容其实已经完整了。最后我想再分享一个小习惯，是我个人在索引维护上最重要的动作——定期检查冗余索引。

联合索引idx_user_status_created(user_id, status, created_at)建好之后，如果表上还有一个idx_user_id(user_id)，那这个单列索引基本就是冗余的，因为联合索引的最左前缀是user_id，已经能覆盖以user_id为条件的查询。冗余索引带来的问题是：写操作要维护多棵B+树，占用额外磁盘空间，而且有些时候优化器还会在候选索引里纠结，反而影响选择。

检查冗余索引的SQL可以直接查information_schema.statistics：

sql复制SELECT table_name, index_name, GROUP_CONCAT(column_name ORDER BY seq_in_index) AS columns
FROM information_schema.statistics
WHERE table_schema = 'your_db'
GROUP BY table_name, index_name
ORDER BY table_name, index_name;

拿到所有索引的字段列表后，人工比对一下哪些索引的前缀和另一条一致，基本就能定位到冗余项。结合慢查询日志和SELECT语句分布，再决定要不要DROP INDEX。

索引这东西，外观看就是把《新华字典》的拼音索引和偏旁部首索引弄清楚，但真值钱的是“什么时候该建、建在哪几个字段上、建完怎么验证、后续怎么维护”这一整套判断力。希望这篇能把你的MySQL查询和索引体系串起来，下次遇到慢SQL，不是抓瞎，而是有条不紊地定位、分析、解决。