不一定绕过主表索引，但极大概率使优化器放弃复合索引前导列；IN子查询常导致全表扫描，改用JOIN或EXISTS（需子查询字段有索引）更易走索引；嵌套中ORDER BY+LIMIT无法复用内层索引顺序。
WHERE 子句里的子查询会绕过主表索引吗
不一定绕过，但极大概率让优化器放弃使用主表的复合索引前导列。关键看子查询是否能被“下推”到扫描阶段——MySQL 8.0+ 和 PostgreSQL 在部分场景支持，但多数情况下，WHERE t1.id IN (SELECT t2.ref_id FROM t2 WHERE ...) 这类写法会让优化器先执行子查询结果集，再对主表做 IN 匹配，此时即使 t1.id 有索引，也可能退化为全表扫描。
实操建议：
- 用
EXPLAIN看type字段：如果是ALL或index，说明没走有效索引；ref或range才算正常 - 把
IN (SELECT ...)改成JOIN，尤其当子查询返回行数较多时，JOIN更容易命中t1.id索引 - 子查询若含聚合或
GROUP BY，基本无法下推，索引利用率直接归零
EXISTS vs IN：哪个更容易用上索引
EXISTS 通常比 IN 更友好，但前提是子查询里相关字段有索引。因为 EXISTS 是半连接（semi-join），优化器更倾向用主表驱动、子查询走索引查找；而 IN 默认尝试物化子查询结果，一旦结果集超阈值（如 MySQL 的 range_optimizer_max_mem_size），就会放弃索引查找转为哈希匹配。
实操建议：
- 子查询中引用主表字段（如
EXISTS (SELECT 1 FROM orders o WHERE o.user_id = users.id)），必须确保orders.user_id有索引 - 避免
IN后接子查询返回NULL——NULL会导致整个条件判为UNKNOWN，可能触发意外全扫 - PostgreSQL 中
IN和EXISTS差异较小，但 MySQL 5.7 及以前版本，EXISTS稳定性明显更高
嵌套查询里 ORDER BY + LIMIT 能否利用索引排序
不能。外层 ORDER BY 无法复用子查询内部的索引顺序，因为子查询结果是临时结果集，不保留物理顺序。即使子查询写了 ORDER BY id LIMIT 10，外层再 ORDER BY created_at，仍需对这 10 行重新排序——但如果子查询本身没索引支撑 created_at，那连这 10 行都未必能高效拿到。
实操建议：
- 把排序和分页逻辑尽量“沉”到最内层查询，比如用
(SELECT * FROM t ORDER BY created_at DESC LIMIT 10)，再在外层过滤，而非反过来 - 如果必须多层排序，考虑用
ROW_NUMBER()窗口函数替代嵌套（MySQL 8.0+/PostgreSQL），它能在单次扫描中完成序号分配和筛选 - 警惕
LIMIT和OFFSET在嵌套中的放大效应：外层LIMIT 10可能导致内层扫描上万行才凑够 10 条满足条件的数据
执行计划里出现 “Select tables optimized away” 是好事吗
是好事，但只适用于极简场景——比如子查询是确定性的标量子查询（SELECT MAX(id) FROM t），且表上有对应索引，优化器直接从索引元数据读出结果，连表都不扫。但它不解决嵌套逻辑本身的低效问题，反而可能掩盖真实瓶颈。
实操建议：
- 看到这行别高兴太早，立刻检查该子查询是否被外层多次调用（比如在
SELECT列表里写多个类似子查询），此时“优化掉”只是单次，实际执行仍可能重复计算 - 如果子查询涉及关联或条件过滤，却也显示这行，大概率是执行计划缓存了旧结果，
FLUSH TABLES或加SQL_NO_CACHE再看 - 真正要盯的是
Extra列里的Using filesort和Using temporary，这两个才是嵌套查询伤索引的实锤
嵌套越深，优化器能做的假设就越少；看似简洁的写法，往往在执行计划里暴露出最原始的扫描行为。别信“语法糖”，信 EXPLAIN ANALYZE 输出的第一行扫描类型。
