MySQL索引底层原理与失效场景全解析：从B+树到联合索引优化

先说个我自己的现场。有一回线上活动报表跑不动，一条 SQL 从几十毫秒干到七八秒，DBA 跑过来让我看。我 EXPLAIN 一放，优化器直接在整张 3000 多万行的表上做全表扫描，而表上明明有两个候选索引，其中一个还是专门为这条 SQL 建的。项目催得急，我到今天还记得当时一行行看索引定义、翻 MySQL 执行计划的心情。后来问题查清楚了：联合索引的三列里，我用了中间一列做等值、最后一列做排序，第一列被写进了函数里，整条索引瞬间“作废”。

从那以后我对“MySQL 索引”这四个字就不再只当它是面试题里背 B+树、背回表、背最左前缀的概念了。这篇文章我就按自己踩坑、看别人踩坑摸出来的路子，把索引相关的底层设计、分类、创建语法、最佳实践、失效场景、优化机制全部过一遍。不敢说“全网最细”，但至少你建索引之前能想到的问题，这文章里基本都能找到答案。

1. 为什么最终活下来的是 B+树：一次磁盘读代价里的数据结构选型

MySQL 的 InnoDB 引擎默认索引结构是 B+树，这个结论几乎所有人都知道。但真要问一句“为什么是 B+树，不是红黑树、不是 B 树、不是哈希”，能讲清楚的人其实不多。要讲透这一点，得先从存储介质的真实物理特性说起。

现代数据库的数据大多在磁盘上，内存只是缓存。业务访问越集中、数据总量越大的表，数据页被驱逐出内存再重新读盘的概率就越高。而磁盘随机读的代价远比你直觉里大得多：内存随机访问大约是 100ns 这个量级，SSD 随机读在 0.01ms~0.1ms 之间，机械硬盘随机读通常在 10ms 上下。换句话说，一次机械硬盘的随机读，差不多是内存读的一万到十万倍，这种量级差异决定了索引结构的首要设计目标不是“算法上快”，而是“尽量少读盘”。

1.1 数据库的预读单位是“页”，不是“行”

如果你对 InnoDB 的磁盘组织方式有观察，应该知道它不仅按行存数据，还把连续空间按 16KB 一页切开。操作系统也有自己的页缓存，InnoDB 和磁盘交互的最小单位就是这一个个“页”。这就引出一个结论：只要走一次磁盘 IO，扛回来的就是整个 16KB 页，而不是某一行的几十个字节。

基于这个特性，一种优秀索引树的设计思路就出来了：让每个节点刚好占用一个页或若干个页，并且节点里能压尽可能多的“路由信息”。B+树的数据页如此，索引页也如此；当你检索时，只需要沿着树从根节点往下走，依次把路上经过的内部节点读进内存就够了。如果在内存里能命中，那全程可能只需要一次磁盘 IO 去读叶子页；如果命不中，则每层都有可能触发 IO。

1.2 二叉树、B树、哈希为什么在这套场景里都不够“香”

很多人会疑惑：B树不也是多路平衡查找树吗？为什么 InnoDB 选的分明是 B+树？可以从三个层面理解。

• 二叉树/红黑树：树太高。假设你存 1000 万行数据，平衡二叉树的高度大约在 24 层左右，每次定位一个叶子可能要访问二十多个节点，每个节点如果不在内存就各是一次磁盘随机读，这代价是致命的。B+树之所以矮，是因为它是多叉的，一个节点里能放几百上千个键值，三层左右就能覆盖千万行数据。
• B 树：B 树每个节点既存索引键也存数据，能利用的“路由密度”被削弱了。非叶子节点中每一条索引记录如果连数据一起占满空间，同一页里能保存的子节点指针数量就少了，树就变高；而 B+树把数据全部收敛到叶子节点，内部节点只存键和指针，可以做到一个 16KB 页里放下上千个键值。这相当于把“树高”这个致命指标压到了可接受范围。
• 哈希表：单点等值查询确实能做到 O(1)，但它天生不适合范围查询和排序。WHERE age > 20 AND age < 40 这种需求在哈希结构里只能全部扫描，而业务 SQL 里范围、排序、分组出现的频率远高于纯粹的等值查询。

从工程角度看，B+树还额外送了一个红利：叶子节点通过双向链表串联。这意味着扫全表、扫索引、范围查询，都能从第一个命中叶子页开始顺着链表顺序读，磁盘层面表现为相对连续的预读，速度比零散随机读高一个量级。所以不是 MySQL 不想用彩虹屁数据结构的“高端算法”，而是它在“磁盘慢、页预读、业务查询多种多样”这三大前提里，选择了最合适的那一棵树。

2. 聚簇索引和二级索引是怎么配合的：从字典说到回表

要理解 InnoDB 的索引结构，脑子里不能只有一棵抽象 B+树，你得把它想象成一本有“正文”和“书后索引”两种用法的大字典。

在 InnoDB 里，表的数据行本身按主键顺序存放在 B+树的叶子页上，主键索引就是一本“正文顺序本身就是索引顺序”的字典。每次你通过主键来查，只要定位到某个叶子页，这一行需要的其他列全都在同一个页里，不需要再做第二次查找。这就是聚簇索引。它对应的叶子节点存储的是整行记录，而不是某个指向其他位置的“书签”。一张 InnoDB 表只能有一个聚簇索引，因为表数据只能有一种物理排序方式，物理上不可能同时按两套顺序摆放数据的“正文”。

而你在非主键列上额外建的索引，属于二级索引，也叫非聚簇索引。它的结构也是 B+树，但叶子节点里存的不是完整行记录，而是“这行数据对应的主键值”。这就像字典末尾的偏旁部首检字表：先通过偏旁找到目标字所在的具体页码，然后再拿着页码去正文里翻。任何一次通过二级索引找到主键后，还要再回聚簇索引里查一次完整行的动作，就是 MySQL 语境下常说的回表。

2.1 每张表都应该有一个有意义的主键

InnoDB 要求每张表必须有聚簇索引。如果你建表时没指定主键，它会先找第一个非空且唯一的索引作为聚簇索引；如果连这也没有，就会生成一个对用户不可见的 6 字节 rowid 作为隐藏主键。这意味着：

• 即使你没有显式建立主键，表在物理层面依然在按某个规则组织。
• 如果不给表设计主键，而让 InnoDB 偷偷生成隐藏主键，那么你的所有二级索引叶子节点存的其实是隐藏 rowid，之后你很难对数据分布做任何主动规划。
• user_id、order_id 等业务上天然稳定的列，比那种事后随意增删的列更适合当主键。

实际项目里，主键选择最常见的大坑是业务订单号、流水号直接当主键。这类字段如果是数字型且递增，问题不大；一旦是 UUID、雪花 ID 中的随机部分，对于 InnoDB 的聚簇索引就是一场灾难。

2.2 自增主键和 UUID 主键的页分裂差异

B+树叶子页按主键顺序维护，新插入的行应该落在“当前最大主键”之后。自增主键恰好满足这种顺序，写入时大多数操作就是不断在 B+树最右侧追加新页，顺序写对机械盘和 SSD 都友好，页分裂概率极低。

但如果是 UUID 这类无序主键，新记录插入时主键值随机会落在已有数据的中段。此时如果目标叶子页已满，InnoDB 就要在中间位置新开一页，把原有的一部分数据搬运过去，这就是页分裂。页分裂不仅放大写入量，还会制造大量索引碎片，导致表空间膨胀与随机 IO 上升。生产上你可以观察一张用 UUID 做主的表和一张自增主键的表，前者的平均行大小往往偏大，且 OPTIMIZE TABLE 之后体量会明显缩小，这就是碎片在作怪。

2.3 一级二级索引的区别决定了 SQL 该选哪些列

因为二级索引要回表，查询能否避免回表，常常是 SQL 性能的分水岭。这里给一个直观结论：

sql复制-- 假设表 user 有 id,name,age,city 四列
-- 二级索引 idx_name_age(name, age)
SELECT id, name, age FROM user WHERE name = '张三';

在这条 SQL 里，二级索引的叶子节点存了主键 id 以及 name、age。优化器在 idx_name_age 上定位到 张三 后，发现需要返回的列（id,name,age）都已经在索引里拿到了，就不需要回表。但如果你把 city 也放进查询列，那么必须拿着主键 id 回聚簇索引读一次 city。这就是回表和覆盖索引在原理层面的区别。

3. 普通索引、唯一索引、联合索引、前缀索引：一张表到底可以建出哪些“路标”

聊完底层数据组织方式，我们可以从使用角度给索引分个类。很多人容易把“主键索引”和“普通索引”对立起来，其实它们只是分类维度不同。索引分类通常有三种切法：

• 按数据结构分：B+树索引、哈希索引（InnoDB 的自适应哈希并非手动创建）、全文索引、空间索引。
• 按逻辑功能分：主键索引、普通索引、唯一索引、全文索引、联合索引。
• 按物理存储分：聚簇索引、二级索引（非聚簇索引）。

实际开发中我们做的最多的是“逻辑功能”这个维度，下面把它展开。

3.1 主键索引与唯一索引：约束强，代价也强

主键索引要求值非空且唯一，一张表只能有一个。它的创建方式有两种：

sql复制CREATE TABLE user (
    id BIGINT NOT NULL AUTO_INCREMENT,
    name VARCHAR(32),
    PRIMARY KEY (id)
);

ALTER TABLE user ADD PRIMARY KEY (id);

唯一索引则允许有多个 NULL 值（MySQL 的 NULL 不等于 NULL，唯一性不冲突），一张表可以有多个唯一索引。常见语法：

sql复制ALTER TABLE user ADD UNIQUE KEY uk_email (email);
ALTER TABLE user ADD UNIQUE INDEX uk_email (email);
CREATE UNIQUE INDEX uk_email ON user (email);

这里必须说一个很多人没意识到的问题：唯一索引不是“在普通索引基础上加个唯一约束”那么简单。每次插入、更新时，InnoDB 都要额外做一次唯一性检查。写入频繁的业务表，唯一索引数量过多会显著拖慢写入。如果你只是为了让某个查询更快，而不需要强约束，没必要建唯一索引。反之，如果业务上要求 email 不得重复，那索引便有了两层价值：约束 + 加速。

3.2 联合索引：最常用的优化手段，也是最容易出错的设计

多个列组合成一个索引，就是联合索引。先看语法：

sql复制CREATE INDEX idx_name_age_city ON user (name, age, city);

它的内部结构依然是 B+树，但排序规则是“先按第一个列排，第一列相等再按第二列排，以此类推”。理解这个组合排序，是后面理解最左前缀原则的前提。

3.3 单列索引与联合索引的选择标准

经常有人把一张表上的每个查询列都建一个单列索引，这是典型的错误姿势。因为 MySQL 的优化器在同一时刻对一张表的多个单列索引，通常只能挑一个用之，很难自动把它们合并成联合索引的效果。当然，MySQL 也提供了 index merge 优化，在某些 AND 条件下把多个单列索引的结果求交集，但它的效率、适用范围都比不上一个设计得当的联合索引。

选择联合索引时，我一般按这个顺序问自己：

1. 这个查询最频繁的过滤条件是哪几列？
2. 如果有排序或分组，是哪些列？
3. 希望让哪几列出现在索引里，能使查询列全部被覆盖、避免回表？

比如业务上高频查 name + age，那 idx_name_age 就比单独的 idx_name 和单独的 idx_age 有价值得多。

3.4 前缀索引：处理超长字符串字段的折中方案

如果一个字段是长字符串，比如用户备注、文章链接、日志消息，直接在整列上建索引会带来两个问题：索引页变大导致树高增加；内存缓冲池能缓存的索引页变少。此时可以只取前 N 个字符建索引，这就是前缀索引：

sql复制ALTER TABLE user ADD KEY idx_name_prefix (name(5));

前缀索引的代价是可能产生误判。比如两个不同的人名前 5 个字符完全一样，那么通过前缀索引定位到的只是一个范围，还需要回表后再精确比较。设计前缀长度时，可以用区分度来测算：

sql复制SELECT COUNT(DISTINCT name) / COUNT(*) AS full_col,
       COUNT(DISTINCT LEFT(name, 5)) / COUNT(*) AS prefix_5,
       COUNT(DISTINCT LEFT(name, 8)) / COUNT(*) AS prefix_8
FROM user;

通常找到“区分度接近整列、长度又尽量短”的前缀即可。

3.5 全文索引：对关键词搜索的补充

B+树索引在 LIKE '%keyword%' 这种模糊匹配下基本无能为力。全文索引则是为全文检索设计，MySQL 从 5.7 开始支持中文全文索引，但需要指定 ngram 解析器。它的底层数据结构是倒排索引，不适合简单理解为 B+树。如果业务系统已经上了 Elasticsearch，全文索引通常可以作为轻量备选方案，但别指望它能替代专业的搜索中间件。

4. 最左前缀与那些让优化器“翻车”的写法：联合索引的正确打开方式

联合索引的高频考点和工程大坑，几乎全部集中在“最左前缀”上。先给一个精确说法：对于联合索引 (a, b, c)，MySQL 需要从左往右逐列匹配查询条件，遇到范围查询（>、<、BETWEEN、LIKE 右侧有通配符的前缀匹配）后，后面的列就无法再用于索引内匹配了。

举例说明，表 user 有联合索引 (a, b, c)：

为什么第一列都匹配不上就一定不行？因为在 B+树中，联合索引的键值排序是先按 a 排，再按 b 排，最后按 c 排。如果你跳过 a 直接给 b 条件，那么所有 b 值会分布在整棵树的多个不同 a 区间里，无法从根节点精确往下路由。这就像一本先按“姓氏”再按“名字”排序的电话簿，只告诉你对方叫“伟”，你根本没法快速定位到某一页，只能从头翻到尾。

4.1 实践中最常见的几类索引失效场景

下面这些场景单独拿出来，在真实慢 SQL 里出现的频率极高。

第一类：对索引列使用函数或表达式

sql复制WHERE DATE(create_time) >= '2025-01-01'
WHERE id + 1 = 5

对索引列套了函数或运算后，B+树里存的是原始列值，不是函数处理后的值，优化器无法利用原始排序关系来直接定位，索引自然失效。DATE(create_time) 这种需求要写成范围条件：

sql复制WHERE create_time >= '2025-01-01' AND create_time < '2025-01-02'

第二类：隐式类型转换

如果表里 phone 字段是 VARCHAR，但查询写成了：

sql复制WHERE phone = 13800138000

MySQL 会把字符串列转换为数字再比较，这相当于在索引列上加了隐式函数，同样导致索引失效。反过来，如果数字列和字符串值比较，优化器通常会把字符串尝试转成数字，也未必能走索引。好的习惯是：应用层传参时就保证类型与表结构一致。

第三类：前导模糊查询

sql复制WHERE name LIKE '%张三%'

因为索引排序是按前缀有序的，左侧有通配符时无法知道目标从哪个键开始。只有右侧通配的 LIKE '张三%' 才能正常走范围查询。业务确实需要中间模糊匹配时，可以考虑全文索引、ES 或加冗余字段。

第四类：OR 连接了一个非索引列

sql复制WHERE name = '张三' OR city = '北京'

即便 name 有索引，只要 city 不是索引列，MySQL 要为 OR 两侧分别取结果集再合并，这很可能导致优化器放弃索引，改用全表扫描。改写思路是用 UNION ALL 拆分两条索引查询，或给 OR 涉及的列都建上合适索引。

第五类：字符集或排序规则不一致

两个表关联时，如果 join 列一个字符集是 utf8mb4，另一个是 utf8mb3，MySQL 为了能比较，会在底层做隐式字符集转换，转换一旦落到索引列上，索引同样会失效。这是做表结构评审时很容易忽略的点，我见过不少多表关联慢 SQL，最后查出来是两套库的字符集不统一。

第六类：优化器判断全表扫描更便宜

这个要特别说明，索引不是“建了就必须用”。MySQL 的优化器会依据索引基数、数据分布、回表成本来判断哪一种方案整体代价更低。如果一张 5000 行的表里 status = 1 的记录占了 80%，在 status 上建索引，优化器很可能直接选择全表扫描，因为这比“通过索引找出 80% 主键，再挨个回表”便宜得多。

4.2 用 EXPLAIN 快速验证一条查询是否真的用了索引

排查索引问题时，不要靠猜，EXPLAIN 是你最好的朋友：

sql复制EXPLAIN SELECT id, name, age FROM user WHERE name = '张三' AND age > 18;

重点关注这些列：

key_len 是个很有用的指标。比如 idx_name_age(name, age)，name 是 varchar(32)，字符集 utf8mb4，因为 name 本身会额外占用 2 字节变长长度，如果 key_len 是 130（32*4+2），说明只用了 name 列；如果变成 134，说明 age 的 INT 也用上了。这个数值能告诉你：你以为的联合索引三列全用，实际上可能只用了最左边一列。

5. 覆盖索引与索引下推：两种让查询省掉大量回表的机制

“回表”是二级索引查询中最昂贵的动作之一。InnoDB 数据按聚簇索引组织，二级索引叶子节点只存主键。如果一次查询命中了 1000 行，每行都要回表，那就差不多要做 1000 次按主键查找聚簇索引的随机读。生产环境里一个明显的现象是：SELECT * 比 SELECT 主键/索引列 慢得多，背后的差距主要来自回表。

5.1 覆盖索引：让查询列全部“住”在索引里

如果查询需要的列都能从当前索引中直接取得，MySQL 就不需要再回聚簇索引捞数据，这种情况叫覆盖索引。此时 EXPLAIN 的 Extra 会显示 Using index。

来看一个例子：

sql复制CREATE TABLE user (
    id BIGINT PRIMARY KEY,
    name VARCHAR(32),
    age INT,
    city VARCHAR(32),
    address VARCHAR(128)
);

CREATE INDEX idx_name_age ON user(name, age);

-- 这条 SQL 只需要 id、name、age，全部可从 idx_name_age 中取得
SELECT id, name, age FROM user WHERE name = '张三';

Extra 出现 Using index 就是覆盖索引生效。但如果再加一个列 address：

sql复制SELECT id, name, age, address FROM user WHERE name = '张三';

这时 address 不在 idx_name_age 里，MySQL 只能拿到主键 id，然后回表读 address，Extra 就会变成 Using index condition 或者干脆没有 Using index。

覆盖索引的实践价值是：高频查询场景可以有意把查询列“塞进”联合索引的后缀里。比如列表页每页 20 条，展示 name、age、city，排序按 create_time，那你完全可以把 create_time 和展示列一并设计进索引。但要注意，索引列越多，写入时维护成本越高，不能为了覆盖而把所有列都塞进同一个索引。

5.2 索引下推：把 WHERE 过滤动作提前到引擎层

索引下推（Index Condition Pushdown，ICP）是 MySQL 5.6 引入并默认开启的优化，作用在联合索引查询时。它的基本原则是：允许在存储引擎层，用索引中的列先做部分过滤，减少回表次数。

讲个容易理解的例子：

sql复制CREATE INDEX idx_name_age ON user(name, age);

SELECT * FROM user
WHERE name = '张三' AND age BETWEEN 20 AND 30;

按最左前缀，name 的等值条件能走索引，age 的 BETWEEN 在 name 都相同的范围内也同样可以利用范围定位。在不支持 ICP 的旧版本中，引擎层先按 name = '张三' 把一批主键找出来，再逐条回表读取完整行，然后在服务层用 age 条件过滤。

开启 ICP 后，引擎层在遍历二级索引时，可以一边定位一边用 age 条件判断，直接把不符合 age BETWEEN 20 AND 30 的索引记录剔除掉，只有真正满足整组条件的记录才回表。这样回表次数大幅减少。在 EXPLAIN 中，ICP 生效的表现是 Extra 显示 Using index condition。

这里提醒一句：Using index condition 和 Using index 是两码事。前者说明走了二级索引且做了部分条件下推，但仍可能回表；后者说明查询列全在索引里，完全不需要回表。优化方向通常是：先追求 ref/range 的访问类型，再追求 Using index 的完全覆盖，最后才考虑 Using index condition 这种“少回表但不是零回表”的中间态。

6. 索引设计实战：从慢 SQL 定位到冗余索引清理，一个完整案例

理论讲太多容易飘，落到一张真实表上才看得清取舍。假设有张订单表：

sql复制CREATE TABLE orders (
    id BIGINT NOT NULL AUTO_INCREMENT,
    order_no VARCHAR(32) NOT NULL,
    buyer_id BIGINT NOT NULL,
    seller_id BIGINT NOT NULL,
    status TINYINT NOT NULL DEFAULT 0,
    total_amount DECIMAL(12,2) NOT NULL,
    create_time DATETIME NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_order_no (order_no),
    KEY idx_buyer_create (buyer_id, create_time),
    KEY idx_seller_status (seller_id, status)
);

线上几个常见查询：

sql复制-- Q1: 买家查看自己的订单列表，通常按时间倒序分页
SELECT id, order_no, total_amount, status
FROM orders
WHERE buyer_id = 1001
ORDER BY create_time DESC
LIMIT 20;

-- Q2: 卖家后台按状态筛选待发货订单
SELECT id, order_no, buyer_id
FROM orders
WHERE seller_id = 888 AND status = 1
ORDER BY id DESC
LIMIT 20;

6.1 先看索引是否解决了排序和分组

Q1 中 buyer_id = 1001 是等值条件，ORDER BY create_time DESC 需要排序。如果只有一个单列索引 idx_buyer(buyer_id)，那么按 buyer_id 查到该买家所有订单主键后，必须再做一次 create_time 排序，即 filesort。而 idx_buyer_create(buyer_id, create_time) 在索引内部就已经按买家再按时间排好序，查询时可以直接顺序扫描 20 条，不需要额外排序，EXPLAIN 里就不会出现 Using filesort。

6.2 覆盖索引改造

Q1 的查询列有 id、order_no、total_amount、status，其中 order_no 本身是唯一索引，如果想让这条高频查询完全覆盖，可以把 idx_buyer_create 扩展成 idx_buyer_create_cover(buyer_id, create_time, order_no, total_amount, status)。但这会造成索引列非常多，写入开销直线上升。

我的取舍建议是：判断这个查询 QPS 高不高。如果一天才调几次，完全没必要覆盖；如果是用户每次进入订单页都会触发，而且查询频率极高，可以考虑用覆盖索引换回表成本。订单表这种高频写入的大表，索引数量更要慎重，索引不是越多越好，每多一个索引，每次 INSERT、UPDATE 都要同步维护，相当于把一次写放大成多次写。

6.3 对 Q2 的调整

Q2 用 seller_id 和 status 两个条件筛选，且按 id 倒序。这里有一个细节：如果卖家的订单量巨大，seller_id, status 的二级索引命中范围可能很大。如果平台只有极少数的“待发货”订单，那么 status = 1 区分度很高，可以把 status 放在最左边，写成 idx_status_seller(status, seller_id)，让优化器先用高区分度列缩小范围。不过这种优化高度依赖业务数据分布，上线前一定要用真实数据量做 EXPLAIN 验证。

6.4 索引维护与冗余检查

在系统迭代过程中，旧的查询可能已经下线，但索引却没删，长期占用空间并拖慢写入。我常用的检查脚本类似：

sql复制SELECT DISTINCT TABLE_NAME, INDEX_NAME
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = 'your_db'
ORDER BY TABLE_NAME, INDEX_NAME;

然后和当前核心 SQL 清单逐一比对，区分哪些索引前缀重复。比如 idx_buyer(buyer_id) 与 idx_buyer_create(buyer_id, create_time)，前者是后者的最左前缀子集。如果确实没有只按 buyer_id 查询且需要避免回表的场景，idx_buyer 完全属于冗余索引，可以删除。如果偶尔有只按 buyer_id 的高频查询，那 idx_buyer_create 也是可以用在 WHERE buyer_id = ? 上的，通常并不需要两个索引同时存在。

6.5 深分页场景的索引优化

再补一个真实实战中常踩的坑。订单列表分页越往后越慢，比如：

sql复制SELECT id, order_no, total_amount
FROM orders
WHERE buyer_id = 1001
ORDER BY create_time DESC
LIMIT 100000, 20;

这条 SQL 直接 LIMIT 偏移 10 万，MySQL 需要先把前 10 万条索引记录扫描出来并丢弃，然后再取后面 20 条，扫描代价很高。索引解决不了“深分页本身要扫描前面记录”的问题，需要通过游标或“延迟关联”改写：

sql复制-- 先只查主键，再 join 回原表取需要的列
SELECT t.id, t.order_no, t.total_amount
FROM orders t
INNER JOIN (
    SELECT id
    FROM orders
    WHERE buyer_id = 1001 AND create_time < '上一页最大时间'
    ORDER BY create_time DESC
    LIMIT 20
) tmp ON t.id = tmp.id
ORDER BY t.create_time DESC;

这种方式关键在于：内层子查询只需要扫描二级索引，不需要回表 10 万次，翻页越深，优势越明显。

在真正的生产环境里，索引设计从来不是“套模板”，而是结合业务 SQL、数据分布、写入频率和磁盘成本一起权衡。我自己做表结构评审时，一定会让每个新索引都能说清楚“它到底服务于哪条 SQL，能否避免 filesort 或回表，能否覆盖高频查询”。如果一条 SQL 因为优化器判断不划算而不走索引，第一反应也不该是立刻加索引，而是检查 SQL 写法是不是触发了函数、隐式转换、前导模糊这类问题。这几板斧用下来，多数慢查询的问题都能在源头化解，而不是靠堆索引来掩盖。