覆盖索引仅在子查询可被优化器合并（非物化）且满足非相关、无聚合/LIMIT/ DISTINCT等条件时才生效；否则物化后索引失效。
覆盖索引对嵌套子查询到底有没有用
没用——如果子查询本身不能被优化器合并，或者用了聚合、DISTINCT、LIMIT 这类“破坏性”操作，那外层加再多索引也没法让子查询内部走覆盖索引。覆盖索引只在「子查询能被展开成 JOIN」的前提下才起作用。物化路径下，子查询先执行完生成临时结果集，此时索引早已失效，你再建 INDEX (a,b,c) 也救不了它。
哪些嵌套子查询能真正受益于覆盖索引
只有满足以下全部条件的子查询，才可能利用上覆盖索引：
- 出现在
FROM子句中（非相关子查询），且不含GROUP BY、DISTINCT、LIMIT、WINDOW、UNION - 外层查询的
SELECT、WHERE、JOIN条件中涉及的列，全部包含在子查询所依赖的基表索引里 - 优化器实际选择了「合并」策略（可通过
EXPLAIN中的select_type显示为DERIVED或直接消失，而不是MATERIALIZED）
例如：SELECT u.name, o.total FROM users u JOIN (SELECT user_id, SUM(amount) AS total FROM orders WHERE created_at > '2024-01-01') o ON u.id = o.user_id，若 orders(user_id, amount, created_at) 是联合索引，且 created_at 条件能走范围扫描，就可能命中覆盖索引，避免回表读取整行。
怎么验证子查询是否走了覆盖索引
关键看 EXPLAIN 输出里的三个字段：
-
key：显示实际使用的索引名，不是NULL -
key_len：值要等于该索引所有被用到列的字节总和（比如INT + VARCHAR(50)utf8mb4 下通常是 4 + 200 = 204），说明全字段都参与了索引查找 -
Extra：必须不出现Using where; Using temporary; Using filesort，理想状态是只有Using index
特别注意：如果 Extra 里有 Using index condition，说明用了 ICP（Index Condition Pushdown），这是好现象；但如果有 Using index for group-by，那说明子查询含聚合，已自动物化，覆盖索引基本无效。
为什么你建了覆盖索引还是没效果
常见原因不是索引建错了，而是写法触发了物化：
- 子查询里写了
SELECT *—— 即使外层只取两列，优化器也无法推断哪些列够用，大概率放弃合并 - 连接条件用了函数，比如
ON u.id = CAST(o.user_id AS SIGNED)，导致索引失效 - 子查询带了
ORDER BY ... LIMIT 10，哪怕外层根本不需要排序，也会强制物化 - MySQL 版本低于 8.0.22，对某些嵌套结构的合并支持不完善
最稳妥的绕过方式：把子查询提前写成 CREATE TEMPORARY TABLE 或 CTE（配合 /*+ USE_INDEX(...) */ 提示），手动控制中间结果规模，再显式建覆盖索引在临时表上。
