嵌套查询本身不是问题，但写法不当会放大IO：JOIN或WHERE中对列用函数（如UPPER、DATE、id+1）导致索引失效而全表扫描；子查询未改写为JOIN易引发多次执行；SELECT *层层包裹增加冗余字段传输；ORDER BY LIMIT置于内层无法下推，应放最外层。
嵌套查询本身不是问题，但写法不当会直接放大IO——尤其在JOIN字段或WHERE里用函数、SELECT *层层包裹、ORDER BY LIMIT塞进内层时，数据库往往被迫反复读磁盘。
别在JOIN或WHERE里对列用函数
比如 UPPER(name)、DATE(create_time)、id + 1 这类表达式出现在关联条件或过滤中，会让索引彻底失效。MySQL、PostgreSQL、SQL Server 都无法走索引查找，只能全表扫描两遍再比对。
- 错误写法：
LEFT JOIN user_info ON UPPER(u.name) = UPPER(i.name)—— 两个表都得算一遍UPPER() - 正确做法：提前建规范列，如
name_upper VARCHAR(64)，加索引，并在业务写入时同步维护 - 替代方案：用大小写不敏感排序规则，如 MySQL 8.0+ 的
COLLATE utf8mb4_0900_as_cs，避免运行时计算 - 验证方式：用
EXPLAIN看type是ref还是ALL；key列是否非 NULL
把子查询改写成JOIN，尤其IN/EXISTS场景
像 SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE region = 'CN') 这种，在 MySQL 5.7 或旧版 PostgreSQL 中极易被优化器判为“相关子查询”，导致外层每行都执行一次内层，IO翻N倍。
- 优先改写为
INNER JOIN customers c ON o.customer_id = c.id WHERE c.region = 'CN' - 如果子查询含
LIMIT或GROUP BY无法直转，用 CTE 强制物化：WITH cust AS (SELECT id FROM customers WHERE region = 'CN' LIMIT 100) SELECT * FROM orders WHERE customer_id IN (SELECT id FROM cust) - MySQL 8.0 用户可开启
semijoin=on（通过SET optimizer_switch='semijoin=on'），让优化器更倾向合并子查询
每一层只选真正需要的字段
SELECT * FROM (SELECT * FROM (SELECT * FROM t1 JOIN t2) t23) t34 看似方便，实则让中间结果集携带大量无用字段，加重网络传输、内存拷贝和缓冲区压力——尤其当某层只用 id 和 status 做后续过滤时，其他字段纯属IO浪费。
- 逐层精简：
SELECT id, status FROM t1 JOIN t2 ON ...→ 外层只基于这两列继续操作 - 给子查询结果起明确别名，避免
Column 'xxx' in field list is ambiguous - PostgreSQL 下可用
EXPLAIN (ANALYZE, BUFFERS)观察Shared Hit Blocks是否异常高，判断是否因冗余字段拖慢缓存命中
ORDER BY + LIMIT 必须放在最外层
把 ORDER BY create_time DESC LIMIT 10 写进子查询里，看起来能早剪枝，但多数数据库（MySQL 5.7、SQL Server）无法保证排序上下文穿透多层嵌套，结果可能错乱，且优化器常无法下推LIMIT到物理扫描阶段，反而多扫一遍再排序。
- 正确位置：
SELECT ... FROM (...) t ORDER BY create_time DESC LIMIT 10 - 前提是
create_time有索引，否则仍会触发文件排序（Using filesort） - 若需分页深度较大（如
LIMIT 10000, 10），考虑用延迟关联：SELECT p.* FROM posts p JOIN (SELECT id FROM posts WHERE ... ORDER BY create_time LIMIT 10000, 10) tmp USING (id)
真正卡IO的地方，往往不在“要不要嵌套”，而在于每层是否清楚自己只需要什么、是否让数据库有机会用上索引、是否把排序和裁剪留到了最后一步。这些点漏掉任何一个，都可能让10万行查询变成秒级响应或数十秒等待。
