嵌套查询慢的根因常是索引缺失或设计不当，而非sql写法；需确保子查询涉及的where条件、select字段等全部被覆盖索引包含，且字段顺序合理，并及时更新统计信息。
为什么嵌套查询慢，其实不总在SQL写法上
很多同学一看到 SELECT * FROM t1 WHERE id IN (SELECT user_id FROM t2 WHERE status = 1) 就去改写成 JOIN，但实际执行慢的根因常是 t2.status 没索引，或 t2.user_id 不在索引里——导致子查询每次都要全表扫 t2。物理存储层没准备好，再怎么重写SQL也白搭。
覆盖索引不是“加个索引就行”，它得把嵌套查询里所有用到的列都塞进一棵 B+ 树里，让引擎不用回表、也不用查主键聚簇索引。
- 子查询中
SELECT的字段（如user_id）必须包含在索引列中 - 子查询
WHERE条件字段（如status）建议放最左，用于快速定位范围 - 如果子查询还有
ORDER BY或LIMIT，排序字段也得进索引，否则无法利用索引有序性
MySQL 覆盖索引设计：字段顺序决定能不能用上
在 MySQL 中，INDEX idx_status_uid (status, user_id) 和 INDEX idx_uid_status (user_id, status) 看似只差顺序，但对嵌套查询影响巨大。前者能走索引扫描 + 覆盖，后者大概率退化为全索引扫描甚至全表扫描。
关键看执行计划里 Extra 字段是否出现 Using index —— 没这个，就说明没真正覆盖。
- 用
EXPLAIN FORMAT=TREE查看嵌套子查询是否被物化（MATERIALIZED），以及物化表是否走索引 - 若子查询带
GROUP BY或聚合，user_id必须在status右侧，否则无法跳过排序步骤 - 避免在索引里加入
TEXT/BLOB列，会直接让索引失效或截断
PostgreSQL 怎么做等价覆盖：用表达式索引和 INCLUDE
PostgreSQL 不支持传统意义上的“覆盖索引”语法，但可以用 INCLUDE 把非键列挂载到索引末尾，效果接近 MySQL 的联合索引覆盖。对嵌套查询尤其有用——比如子查询只查 user_id，但过滤条件是 status = 'active'，那就建 CREATE INDEX ON t2 (status) INCLUDE (user_id)。
注意：INCLUDE 列不能用于 WHERE 或 ORDER BY，只能用于 SELECT 输出列覆盖。真要支持过滤+输出双覆盖，还是得上表达式索引。
-
INCLUDE列不参与 B-Tree 排序，所以不会增加索引深度，但会增大索引体积 - 若子查询有
LOWER(email)这类计算，必须用表达式索引：CREATE INDEX ON t2 ((LOWER(email))) INCLUDE (id) - PostgreSQL 12+ 才支持
INCLUDE，老版本只能靠联合索引硬凑，且要注意字段顺序和数据类型隐式转换
容易被忽略的物理细节：统计信息不准会让覆盖失效
即使你建了完美的联合索引，ANALYZE 没跑过、或者表数据大变后统计信息过期，优化器也可能误判“走索引不如全表扫”，直接放弃你的覆盖索引。这不是 SQL 写得不对，是元数据没更新。
尤其当嵌套查询返回结果集很小（比如几十行），但优化器以为有几万行时，它宁可走主键扫描也不走二级索引——因为预估成本高。
- 执行
ANALYZE t2强制刷新统计信息，比等自动触发更可靠 - 对大表，考虑调大
default_statistics_target（比如从 100 改到 500），让采样更准 - 检查
pg_stats表里t2.status的n_distinct是否明显偏离真实值，偏了就得ANALYZE
嵌套查询的性能瓶颈，八成卡在索引能不能真正覆盖子查询的全部访问路径——而不是人肉重写 SQL。字段顺序、统计信息、引擎特性这三块，漏掉任何一块，覆盖索引就只是摆设。
