嵌套查询本身不破坏索引，而是触发优化器放弃前导列索引、强制物化、重复解析JSON/XML字段、外层排序无法复用索引顺序、NOT IN遇NULL导致全表扫描等行为使索引失效。
绝大多数情况下，不是嵌套查询“本身”破坏索引，而是它触发了优化器放弃使用主表索引前导列、强制物化子查询、或反复解析非结构化字段——这些行为让索引形同虚设。
WHERE 中的 IN (SELECT ...) 让复合索引前导列失效
当主表有 idx_user_status（user_id, status）这样的复合索引，而你写 WHERE user_id IN (SELECT ref_id FROM logs WHERE type = 'login')，MySQL 很可能不走 idx_user_status 的 user_id 部分，哪怕 user_id 单独有索引。
- 原因：优化器倾向先执行子查询，得到结果集后做哈希匹配或逐行 IN 判定，不再尝试用
user_id索引驱动扫描 - EXPLAIN 里
type是ALL或index，而不是ref或range - 修复方式：改写为
JOIN logs ON orders.user_id = logs.ref_id WHERE logs.type = 'login'，并确保logs(ref_id, type)有合适顺序的索引
子查询含 XML/JSON 字段时，B+树索引完全不生效
WHERE JSON_EXTRACT(payload, '$.user.id') = '123' 或 WHERE profile.exist('/order/@status') = 1 这类条件，无论外层怎么嵌套，数据库都必须逐行解析整个字段内容。
- XML/JSON 类型字段无法被 B+ 树索引直接覆盖；索引只对提取后的值有效
- 嵌套会让解析次数放大：外层每匹配一行，内层可能重新解析一次
profile字段 - 真正有效的解法不是改写嵌套，而是物化关键路径：
ALTER TABLE customers ADD user_id AS payload->>'$.user.id' STORED，再在user_id上建索引
ORDER BY + LIMIT 出现在子查询里，外层排序无法复用索引顺序
写成 SELECT * FROM (SELECT * FROM orders ORDER BY created_at DESC LIMIT 10) t ORDER BY id，看起来很合理，但实际是两轮排序：子查询里按 created_at 排，外层再按 id 重排。
- 子查询的
ORDER BY只保证临时结果集顺序，不传递给外层；外层仍需对这 10 行重新排序 - 如果
created_at没索引，子查询本身就得全表扫描+文件排序，性能雪崩 - 更稳妥的做法是把排序沉到最内层：
SELECT * FROM orders WHERE ... ORDER BY created_at DESC LIMIT 10，别套壳 - MySQL 8.0+ 可考虑
ROW_NUMBER() OVER (ORDER BY created_at DESC)替代嵌套
NOT IN 遇到 NULL 值导致全表扫描且结果意外为空
SELECT * FROM orders WHERE user_id NOT IN (SELECT id FROM users)，只要 users.id 里有一条 NULL，整条语句就返回空——不是逻辑错，是 SQL 三值逻辑的必然结果，而且优化器常因此放弃索引。
-
NOT IN在遇到任意NULL时判定为UNKNOWN，被当作FALSE过滤掉 - 优化器看到子查询可能含
NULL，往往拒绝走user_id索引，退化为全表扫描 - 一律改用
NOT EXISTS：WHERE NOT EXISTS (SELECT 1 FROM users u WHERE u.id = orders.user_id)，既避开了NULL陷阱，也更容易命中users(id)索引
真正难处理的从来不是语法嵌套本身，而是嵌套背后隐含的执行路径不可控：物化、重复解析、锁顺序混乱、条件下推失败。盯着 EXPLAIN 里的 DEPENDENT SUBQUERY、DERIVED、Using temporary; Using filesort 这些信号，比纠结“能不能用子查询”更有价值。
