企业官网建设流程全解析

联合索引的最后一公里：把最左前缀、覆盖索引和ICP彻底串起来

上周排查一个线上慢查询，日志里一条select * from order_info where user_id = ? and status = ? order by create_time desc limit 20竟然跑了将近1秒。表里才三百多万行，索引也建了，理论上不该这么慢。我顺着执行计划一层层往下剥，最后发现根子出在索引设计上：建了一个(user_ id, create_time, status)的联合索引，字段顺序不合理，导致原本能走覆盖索引的查询被迫回表，还得额外做一次 filesort。调完索引结构后，同样一条 SQL 从 900ms 降到 8ms，上百倍的差距。

很多开发者对 MySQL 索引的认知停留在“背结论”的层面——知道“最左前缀”“覆盖索引”“ICP”这些词，也知道explain里有Using index、Using index condition这些标记，但一旦要独立设计索引、排查慢查询，就不知道这些理论到底怎么落到实战里。这篇文章就把这三个经常被分开讲解、实际却紧密咬合的概念放在一起串讲一次，从底层原理到可复现的执行计划，给出一套能直接套用的索引设计参考。

这条学习路径适合正在进阶的后端开发者，尤其是写过一段时间业务 SQL、准备系统性提升数据库调优能力的人。我会先从为什么联合索引能命中“最左前缀”讲透，再讲覆盖索引为什么是查询性能的质变，最后落到 ICP 这个很多人知道名字却不知道它到底干了什么的功能上，用同一张表的多个查询场景把三者的分工和配合完整还原出来。

1. 最左前缀：联合索引的本质是“有序的复合字典”，不是字段的随意排列

最左前缀（Leftmost Prefix Principle）是联合索引一切行为的总纲。理解它的前提，是先接受一个事实：MySQL 里的联合索引本质上是一棵以字段组合为排序键的 B+ 树，排序规则是“先按第一个字段排，第一个字段相同再按第二个字段排，依此类推”。这个行为和电话簿先按姓、再按名排序，再按中间名排序的逻辑完全一致。

1.1 为什么只靠最左几个字段就能加速查询：B+树目录的物理结构

假设有一张用户账户流水表，我们建了联合索引idx_user_time (user_id, create_time)。这颗 B+ 树的非叶子节点里，每个目录项都是(user_id, create_time)的组合值，并且严格按照“先 user_id，再 create_time”的顺序组织。查询条件where user_id = 9527 and create_time >= '2024-01-01'时，MySQL 的优化器能够在 B+ 树里先根据user_id = 9527锁定账户目录分组，再在组内快速定位到create_time的开始位置，整个过程是树层级的快速移动，不需要扫描全索引。

但换成where create_time >= '2024-01-01' and user_id = 9527，条件字段还是这两个，最左前缀依然有效。这一点是新手最容易误读的地方——误以为“WHERE 里必须先写 user_id 才走索引”。实际上优化器会做条件重排，只要查询条件里存在索引的最左字段等值条件，能和索引前缀匹配上，它就生效。真正会让索引失效的，是查询条件里完全缺少索引的第一个字段，比如只查where create_time >= ?，这时 MySQL 无法在 B+ 树里确定从哪个 user_id 分组开始扫描，只能全索引扫描。

1.2 什么时候“从左到右”会被打断：范围条件与字段顺序的取舍逻辑

最左前缀的“前缀”是个严格概念。where user_id = ? and create_time > ? and status = ?配合索引(user_id, create_time, status)，只有前两个字段能利用索引定位，status条件无法在索引树里直接过滤，只能退化为对(user_id, create_time)定位出的索引范围内做逐条过滤。

说明白一点：联合索引里，一旦出现范围条件（>、<、between、like前缀等），它后面的字段就部分失效了，精确匹配能力断在范围列这里。这不是 MySQL 的缺陷，而是 B+ 树的排序规则决定的——(user_id, create_time, status)排序时，status 只在 user_id 和 create_time 都相同的前提下才有序，一旦 create_time 是一个范围，范围边界之间的记录在 status 字段上乱序存储，索引树无法继续用二分查找定位 status。

不过这里有个实战里几乎人人踩过的坑：等值条件应该在联合索引里尽量靠前，范围条件尽量放在最后。比如条件user_id = ? and status = ? and create_time > ?，索引应设计为(user_id, status, create_time)，让两个等值条件都吃掉前缀，把唯一一个范围字段放末尾。这样整条查询都能命中最左前缀，范围条件对后面的字段也没有“需要断开”的压力。很多人建索引时习惯按业务查询里字段出现的先后顺序排列，这是错的；正确的顺序是“等值优先，过滤性强的优先，范围最后”。

1.3 一个容易误判的场景：IN列表到底算等值还是范围

where user_id in (1,2,3) and create_time > ?里，IN虽然写法上像范围，但优化器会把它展开成多组等值条件的并集，因此IN列表对索引前缀的消耗方式和等值条件完全一致，create_time的范围条件仍然可以继续使用索引。这一点在处理“多用户账单筛选”这类场景时非常重要：(user_id, create_time)索引能完整支撑查询，不会因为 IN 而断掉 prefix。

需要注意的是 IN 列表不宜过长。列表元素很多时，优化器可能评估出“每组等值都走索引不如直接全表扫+过滤”，转而选择暴力扫描，执行计划里 key 会变空或者出现Using where，这类行为在不同数据分布下波动较大，不能只依赖脑内推演，必须实际跑 explain。

2. 覆盖索引：不只是“省一次回表”，而是把随机I/O换成顺序扫描的质变

覆盖索引（Covering Index）指的是查询所需要的全部列，都能在索引树里直接取得，不需要再从聚簇索引里读取完整行。实现它的前提是索引列“覆盖”查询列，包括 WHERE 条件列、ORDER BY 列、SELECT 的返回列以及 JOIN 的关联列。

2.1 回表为什么是性能杀手：两层索引结构决定了行定位必须二次跳转

InnoDB 的两层索引结构中，聚簇索引（主键索引）的叶子节点存的是整行数据，二级索引的叶子节点存的是“索引列 + 主键值”。正常情况下用二级索引定位到目标主键后，还需要再根据主键去聚簇索引里找一次完整数据行，这次动作就叫回表。回表的代价不在于次数少，而在于它是随机 I/O——每回表一次，都可能触发一次磁盘寻道。机械硬盘上随机 I/O 的耗时可高达数毫秒，即使是 SSD，随机读也远贵于顺序读。

覆盖索引的价值就是把“二级索引命中 + 回表”变成“只读二级索引”，把随机 I/O 完全消掉，变成对索引叶子节点相对连续的顺序扫描。举个例子，表account_flow上建了idx_user_time(user_id, create_time)，执行select user_id, create_time from account_flow where user_id = 9527，这棵树本身就包含 user_id 和 create_time，不需要再读聚簇索引，explain的 Extra 列会显示Using index。这就是教科书里的最优状态。

2.2 覆盖索引与最左前缀的关系：前者的设计优先级甚至要排在字段顺序之前

这里有一个必须建立的认知：覆盖索引不要求“覆盖全部条件的最左前缀”，而是要求“SELECT 涉及的所有字段都在索引内”。一个查询可能是带范围条件、可能还带排序，但只要所有用到的列都在索引里，即使条件匹配只用到部分前缀，查询依然能从索引树直接拿到所需数据，省去回表。

举个例子，索引(user_id, status, create_time)，查询select user_id, create_time from order_info where user_id = 9527 and status = 1 and create_time > '2024-01-01'。因为 SELECT 只返回 user_id、create_time 两列，索引里都有，即便 create_time 后的 status 条件无法继续精确过滤，整条查询也可能不需要回表——条件列都在索引里，数据也都在索引里，直接拿索引记录过滤后输出就行。Extra 里往往是Using where; Using index。

不过要注意，Using index不代表没有过滤动作，只代表“没回表”。Using where表示在索引层拿到的数据还要做一次条件过滤再输出，但整体成本依然远低于回表。

2.3 覆盖索引的代价：别为省回表把索引膨胀成“小表复制”

覆盖索引的好用会让新手走上另一个极端——为了让所有查询都覆盖，把几十个字段全塞进索引里。这是一个必须泼冷水的点：索引也是 B+ 树，也是要占用磁盘空间、要参与写入维护的。索引列越多，索引体积越大，单页能容纳的索引记录越少，扫描效率越低；每次 INSERT、UPDATE、DELETE 都要同步维护每一颗索引树，写放大直接翻倍。

因此设计覆盖索引要在“高频慢查询”和“写入成本”之间找平衡点。我的经验是：只做两类覆盖索引设计能力范围内的动作——把高频的等值条件列放在左侧；把 SELECT 高频返回的少量列（比如状态、时间、金额、标题这类短字段）放置在索引右侧；大字段、TEXT 前缀、几乎不查询的列千万不要为了凑覆盖放进去。对真正高频且查询列固定（如列表页），为了一个 SELECT 列设计专用覆盖索引完全是划算的；对低频导出类查询，宁可让它回表，也不要为了少一次回表而背两个索引的维护成本。

3. ICP（索引条件下推）：MySQL 5.6 之后，回表行数被砍掉一半的幕后功臣

索引条件下推（Index Condition Pushdown）是全文中最后一个概念，也是三个里面最容易被低估的。很多人会把Using index condition误读成“用了覆盖索引”，这是一个高频误判，后文会专门对比。

3.1 ICP 解决了什么问题：从“先回表再过滤”到“先过滤再回表”

在没有 ICP 的 MySQL 5.6 之前，二级索引的查询流程是这样的：存储引擎通过索引定位到满足前缀条件的记录主键，拿到主键后立即回表读取完整行，在 Server 层再用剩余的 WHERE 条件逐行过滤。问题是，如果过滤条件中有很多列其实也在索引里，先回表就意味着白白做了一堆随机 I/O。

ICP 的思路很直接：把部分 WHERE 条件判断下推到存储引擎层，在索引遍历过程中先做条件过滤，过滤不掉的再回表。这样回表次数从“索引命中的所有记录数”降为“索引命中且通过条件下推的记录数”，经常能砍掉一半以上的回表。

举一个最直观的例子。索引(user_id, status)，查询select * from order_info where user_id = 9527 and status = 'C'。没有 ICP 时，存储引擎会把 user_id = 9527 的所有索引记录全捞出来，全部回表取行，Server 层再逐行判断 status。有 ICP 时，存储引擎在索引树上遍历到 user_id 分组内的每一条记录时，直接检查该记录的 status 列是否等于 C，不符合的当场丢弃，只有符合的才去回表。如果小明有 1000 条流水订单里只有 20 条是 C 状态，回表次数就从 1000 降为 20，效果立竿见影。

3.2 Using index 和 Using index condition 的区别：一个是不回表，一个是少回表

explain里这两条 Extra 信息是面试和实战中经常被混淆的：

• Using index：不回表，查询所需的全部数据都从索引直接获得，这是覆盖索引。
• Using index condition：有索引条件下推，存储引擎在索引层先做了一部分过滤，但仍有“剩余字段”必须回表读取后才能判断、返回，这是 ICP 生效的标识。

它们的区别本质上是“查询字段是否都在索引里”。select *几乎不可能出现Using index（除非索引里包含整张表的所有列，现实中极少），但可能因为条件列被下推而显示Using index condition；反之select 索引列且过滤字段也在索引里，则可能显示Using index。两者可以同时出现——比如查询列在索引树里就能取到，而 WHERE 中的另一部分列参与下推，Extra 会显示Using index condition; Using index。

3.3 ICP 的触发条件与边界：不是所有条件下推都有收益

ICP 的触发有几个硬性约束，理解这些约束对判断“这个查询能不能吃 ICP”很有帮助：

• 底层存储引擎必须支持“索引条件下推”的 API。InnoDB 和 MyISAM 都支持，这是默认开启的（optimizer_switch里的index_condition_pushdown=on）。
• WHERE 条件中下推的列必须是查询所用索引的组成部分，且下推的是“在索引层级能完成判定的条件”。比如索引(user_id, status)中下推status = 'C'，索引记录里能直接拿到 status 列，判断成本极低。但如果条件是order_note like '%紧急%'且 order_note 不在索引里，就无法下推，只能回表后过滤。
• 主键索引（聚簇索引）上的条件不需要 ICP，因为聚簇索引本身就在行数据上，不存在回表一说。
• ICP 不适用于分区表（目前 MySQL 8.0 仍有部分限制），逻辑复杂的分区场景需要兼容考虑。

实战中判断一个查询是否吃到 ICP，最快的方法就是 explain 后看 Extra 是否包含Using index condition。如果有，且你的查询是典型的“索引前缀命中 + 后续前缀字段过滤”组合，这说明优化器把过滤压到了引擎层，收益非常可观。

4. 三者配合的实战推演：同一张表的三个查询，把执行计划拆给你看

理论讲完，我们落到一张典型的电商订单表上，把三个机制放在同一个场景里完整推演一遍。表结构如下（字段做了精简）：

CREATE TABLE `order_info` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `user_id` varchar(32) NOT NULL COMMENT '买家ID', `order_no` varchar(64) NOT NULL, `status` tinyint(4) NOT NULL COMMENT '1待支付 2已支付 3已发货 4已完成 5已取消', `item_cnt` int(11) NOT NULL DEFAULT '1', `pay_amount` decimal(12,2) NOT NULL DEFAULT '0.00', `create_time` datetime NOT NULL, `pay_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_user_time_status` (`user_id`,`create_time`,`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

业务上有三个典型查询：

• 查询某个用户在某个时间段的订单列表，按时间倒序：select id, order_no, status, create_time from order_info where user_id = ? and create_time >= ? and create_time < ? order by create_time desc limit 20
• 查询某个用户待支付订单的笔数和金额汇总：select count(*), sum(pay_amount) from order_info where user_id = ? and status = 1
• 查询某个用户在某个时间内已完成订单的金额分布：select pay_amount from order_info where user_id = ? and create_time >= ? and create_time < ? and status = 4

分别看这三条 SQL 在现有索引idx_user_time_status(user_id, create_time, status)下的表现。

4.1 场景一：等值 + 范围 + 排序，最左前缀解决了“快跑”的问题

第一条 SQL 的过滤条件是 user_id 等值 + create_time 范围，排序按 create_time desc。这个场景 index 设计恰好能完美命中：优化器用 user_id = ? 定位分组，用 create_time 范围锁定索引区间，然后在索引区间内按逆序遍历（InnoDB 索引叶子节点是双向链表，tail 端向前扫即可实现 desc），不会触发 filesort。SELECT 里的 id、order_no、order_no 不在索引里，因此需要回表。

执行计划近似：

id select_type table type range key extra 1 SIMPLE order_info range idx_user_time_status Using index condition

这个查询吃到了 ICP 吗？严格说，“Using index condition”在这个 SQL 里是否出现，取决于优化器是否把状态判断下推。本例 create_time 范围确定出的区间内，status 依然是乱序的，status 条件在索引树上无法直接连续定位，但仍可在遍历索引时即时读取并 skip，所以 Extra 大概率是Using index condition; Using filesort都不会有，就一个干净的Using index condition。因为查询列需要回表，且回表前在索引层就过滤掉了大量不符合的 status，这正是 ICP 的典型收益场景。

4.2 场景二：字段都在索引里，覆盖索引直接起飞，连回表都省了

第二条查询select count(*), sum(pay_amount) from order_info where user_id = ? and status = 1。这个查询比较特殊：count(*)不需要读取真实行，只要能数清记录数即可；sum(pay_amount)则需要从某一列取数值。问题来了：pay_amount 不在索引idx_user_time_status里，覆盖索引的理想形态被破坏，执行时即使能通过 user_id + status 的组合过滤，仍要回表取值。

如果这张表的这个查询足够高频，就应该在前文提到的“用空间换回表”思路指导下，做成一个覆盖查询，比如建立一个冗余的联合索引idx_user_status_amount(user_id, status, pay_amount)。改造后explain里 Extra 会变成Using where; Using index，注意到pay_amount也从索引直接读出，sum 不再依赖回表。几百个订单的场景可能看不出差别，但当某个用户的订单数据膨胀到十万级只取二十条统计时，这个改动直接决定接口是 200ms 还是 8ms。

4.3 场景三：范围加上等值，索引顺序错了就是典型的慢查询翻车现场

第三条查询select pay_amount from order_info where user_id = ? and create_time >= ? and create_time < ? and status = 4。这个查询完全暴露了索引(user_id, create_time, status)的缺陷：user_id 和 create_time 能快速锁定范围，但 status 被范围条件切断，无法继续在 B+ 树里精确定位。如果用户在这个时间段内有大量不同状态订单，status = 4的过滤就只能在索引遍历过程中逐条判断。

此时，前文强调的“等值优先、范围最后”就体现出来了。正确的索引设计应是(user_id, status, create_time)——先用 user_id + status 两个等值条件用最左前缀精确定位到用户与状态的组合区间，再用 create_time 做范围扫描，pay_amount 如果也塞进该索引的末尾，还能直接从索引取值，形成“最左前缀 + 覆盖索引 + ICP”三合一的最优组合。

4.4 同一张表两个索引殊途同归：从执行计划回推设计取舍

从上面三个场景可以看到，联合索引的字段顺序设计，其实是对“查询字段组合的等值频率、范围频率、排序方向、覆盖需求”的总体取舍。没有业务流量画像，就没有所谓“标准答案”。一个常用的设计流程是：

1. 列出该表最重要、最高频的 5 条查询（特别是列表页和统计查询）。
2. 对每条查询，圈出 WHERE 的等值列、范围列、ORDER BY 列、SELECT 返回列。
3. 按“等值列优先（区分度高的靠前）→ 范围列放最后 → 若高频 SELECT 列未覆盖则逐一加入 → 最终控制每个索引的列数不超过 4~5 个”的规则设计。
4. 每设计一个索引，用 explain 验证是否出现Using index或Using index condition，并估算扫描行数是否大幅下降。
5. 对每个索引估算写入维护开销，宁可索引数量少而精，也不要为了让“每条 SQL 都覆盖”而加一堆重复索引。

5. 排错实战：explain 里的几个常见误判和一眼定位方法

理论扎实之后，排错能力的差异就是细节功底。这里给出几个实战里反复遇到的场景，都是可以直接照搬的判断思路。

5.1Using where不一定没走索引：真正要看的是 type 和 key

很多同学看到 Extra 里出现Using where就认为“索引没生效”，这个判断是错误的。Using where只表示 MySQL 在拿到索引命中的记录后还需要再做一层条件过滤（可能是索引范围边界之外的条件，也可能是回表后判断的字段），不代表全表扫描。判断索引是否生效，核心指标是key列是否使用到索引、type是不是 range/ref/eq_ref/const。只有type变为ALL、key为 NULL 时，才能判定索引完全失效。

比如where user_id = ? and create_time > ? and status = ?在(status, create_time, user_id)索引下可能 key 非 NULL，但 status 等值条件在索引后段，过滤能力没吃满。正确的判断姿势永远是“key + type + key_len + rows + Extra”五列一起看，而不是揪着某一个标记下手。

5.2 key_len 的计算：一眼看出索引真正被用到了哪一列

key_len是很多调优者忽略、但信息量极大的指标。它表示 MySQL 在执行计划中实际使用的索引字节长度。通过key_len可以反向推断最左前缀命中了索引的哪些列。

联合索引(user_id varchar(32), create_time, status tinyint)，三列都用到时的 key_len 大致为：user_id 按 utf8mb4 实际最大占用 32*4+2（变长字段） = 130 字节；create_time 为 5 字节（date 为 3、datetime 为 5、timestamp 为 4，你用的版本默认以 datetime 存储为 5 字节）；status tinyint 为 1 字节，合计约 136 字节。如果 explain 显示 key_len 只有 130，说明只命中 user_id；130+5=135 说明命中 user_id + create_time；136 才表示三段全命中。看执行计划时脑海里快速算一下 key_len，就能确认优化器到底把索引吃了多长，比单纯相信直觉靠谱得多。

注意 varchar 的 key_len 按“实际字段最大字节 + 变长标识 2 字节”计算，且与字符集相关，utf8mb4 一个字符占 4 字节（MySQL 8.0 默认）。date 类型占 3 字节也常被记错，这里顺手列个表备用：

5.3 filesort 是排序的退路：索引排序和 filesort 的分界线依然与最左前缀强相关

order by create_time desc是否产生 filesort，取决于排序字段是否为当前索引的可用后段。在索引(user_id, status, create_time)下执行where user_id = ? and status = 1 order by create_time desc，等值列 user_id、status 正好固定住前两列，create_time 的排序自然连续，直接逆序扫即可。如果查询条件缺少 status 这个等值列，只用 user_id = ? 去定位，那么 create_time 在 user_id 分组内仍是全局有序，依然可以走索引排序，也不会 filesort——因为在联合索引中，只要第一个等值列确定，紧跟着的第二个列（即便没条件是排序列）也是局部有序的。

但如果查询条件变成where user_id = ? and create_time > ? order by status asc，因为 create_time 范围破坏了对 status 的局部分组连续性，排序就只能在临时表里做，Extra 会显示Using filesort。此时要么调整查询条件让 status 参与等值匹配，要么重新设计索引，要么接受 filesort 的临时表开销。如果你的列表接口要求排序稳定，这条分界规则必须刻在脑子里。

6. 索引设计的几个反向教训：我踩过的“索引冗余”和“过度优化”坑

理论一套完整，最后分享几个真实项目里反复出现的教训，这些都是常规 doc 里不会写、但在业务代码里几乎必然遇到的经验。

6.1 重复索引比不建索引更危险

一个常见的错误是为了“让每个查询都有覆盖索引”，对同一组字段建了多个顺序稍有不同的联合索引，比如(user_id, create_time)和(create_time, user_id)同时存在。如果业务查询总是 user_id 为前缀，那第二个索引就是典型的重复索引——它占空间、拖慢写入，实际却不被任何高频查询使用。MySQL 8.0 的explain里可以用ANALYZE FORMAT=JSON查看每个候选索引的成本评估，但在做这件事之前，先手工用sys.schema_unused_indexes和sys.schema_redundant_indexes这两张视图清理历史残留，也是好习惯。

6.2 “为了覆盖而覆盖”导致索引体积爆炸

早期我曾在订单表上把 8 个字段放进了同一个“覆盖所有列表查询”的索引里，包括一个order_note varchar(1000)。线上跑了一周后发现问题：索引磁盘占用超过了数据本身的 60%，更致命的是，因为索引体积太大，B+ 树的扇出变低，索引层数变深，实际查询扫描的索引块数量反而上升了，性能不升反降。后来把这类大字段移除，只保留order_no, status, create_time, pay_amount，查询性能恢复，写入也不再抖动。覆盖字段必须控制在“常用短列”范围内，这是铁律。

6.3 最左前缀是规则，但优化器也会耍小聪明：OR 条件导致索引失效

where user_id = ? or create_time > ?这种条件，优化器通常无法直接用一个联合索引组织出高效的执行计划，index merge 的开启情况在不同版本、不同数据量下表现不稳定，更稳的写法是拆成两个查询用 UNION 合并。这个问题几乎每个业务里都会碰到，值得在写 SQL 时多一点关注：

-- 原写法（可能失效） select * from order_info where user_id = 'u001' or create_time > '2024-01-01'; -- 改写成 UNION 的等价形式 select * from order_info where user_id = 'u001' union all (select * from order_info where create_time > '2024-01-01' and user_id <> 'u001');

OR两侧如果都是普通列且非前缀关系，索引命中的不确定性较大，而改写后两条查询分别能命中不同索引段，执行计划更可控。

7. 回归到业务流量：给一张表设计索引的完整决策路径

最后把整套内容收敛成一条可复用的决策路径。拿到一张表、一堆慢查询时，我建议按下面的顺序走一遍，基本能把大多数简单索引问题解决掉：

1. 用慢查询日志或 performance_schema 找到 TOP 10 高频且慢的 SQL。
2. 每条 SQL 都区分出等值列、范围列、排序列、返回列四组。
3. 按“等值列优先（区分度高优先）→ 范围列靠后 → 覆盖列补充”的顺序组合索引。
4. 为每个候选索引评估写入维护成本，去掉重复、冗余、低收益的索引。
5. 用 explain 验证执行计划的 key、type、key_len、rows、Extra，确认每个索引都“被真实使用”。
6. 上线前用sys.schema_index_statistics持续观察一段时间，清理无效索引。

这条路径里，最左前缀负责保证索引能被“走到”，覆盖索引负责让“走到了之后少回表”，ICP 负责在“必须回表”的场景下尽量少回表。三者层层递进，从定位到过滤到回表，每一层都在削减 I/O 次数。理解了这条链路，你设计索引时就不是在“套模板”，而是真正知道每条 SQL 的数据访问路径长什么样，也知道为什么某些索引结构看着合理、实际却带不来提升。

如果你现在手头正好有一条慢查询，不妨按上面的方式打开 explain，先算一下 key_len，再看看有没有Using index condition或Using filesort，然后从字段顺序开始排查——大概率你很快就会找到那个拖慢一切的索引设计决策。