标量子查询强制嵌套循环，每行触发一次子查询执行：主表每行都完整执行子查询，100万行即执行100万次；即使有索引也仅加速单次扫描，无法减少调用次数，总复杂度o(n×m)，易导致全表扫描和性能崩塌。
标量子查询强制嵌套循环，每行触发一次子查询执行
数据库看到 SELECT a.id, (SELECT SUM(b.val) FROM b WHERE b.a_id = a.id) 这类结构时，不会预先计算所有分组聚合结果，而是对主表 a 的每一行都完整执行一遍子查询。这意味着：若 a 有 100 万行，子查询就执行 100 万次；哪怕 b 表只有 5 万行，每次仍要走解析、计划生成、索引查找（即使条件相同）、聚合全流程。
常见错误现象：EXPLAIN 输出中频繁出现 SubPlan 或 InitPlan 节点，且每个都带 Seq Scan 或重复的 Index Scan；真实耗时远超预估，EXPLAIN ANALYZE 显示子查询部分占总耗时 90% 以上。
- 即使
b(a_id, val)有复合索引，也只能加速单次扫描，无法规避调用次数本身 - 若子查询中
WHERE条件列未建索引，会直接退化为对b表的百万次全表扫描 - 主表扫描与子查询扫描形成双重线性开销，总复杂度是
O(N × M)，而非O(N + M)
相关子查询改写为 JOIN 时的行为差异极易被忽略
表面上把 (SELECT COUNT(*) FROM orders WHERE orders.user_id = users.id) 改成 LEFT JOIN (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) o ON users.id = o.user_id 就能提速，但实际落地常踩三类坑：
-
NULL处理不一致：原标量子查询无匹配时返回NULL；JOIN 后若没加COALESCE(o.cnt, 0)，cnt字段可能为NULL，业务逻辑出错 - 多行报错机制丢失：标量子查询若因数据异常返回 2 行，会立刻报
ERROR: more than one row returned by a subquery used as an expression；而 JOIN 会静默产生笛卡尔积，污染结果且难以定位 - 空集聚合行为混乱：例如
AVG()和SUM()在空组中返回NULL，但COUNT()返回0；混用时改写逻辑稍有偏差，统计口径就完全跑偏
优化器难识别语义等价性，盲目改写反而更慢
数据库内核必须确保改写前后行为 100% 一致，但很多看似等价的写法在边界条件下结果不同。比如用 EXISTS 替代 IN，错误写法 WHERE EXISTS (SELECT 1 FROM tmp_ids) 实际变成常量判断，全表扫描；正确写法必须带关联条件 WHERE EXISTS (SELECT 1 FROM tmp_ids t WHERE t.id = o.user_id)，且 tmp_ids.id 必须有索引，否则内部仍是全表扫描。
性能/兼容性影响：MySQL 5.7+ 对 IN 列表长度有隐式限制（如 max_allowed_packet 溢出导致截断）；PostgreSQL 的 planner 在深层嵌套子查询中成本估算严重失准，可能放弃可用索引，选错连接方式。
- 拆解嵌套时，用
WITHCTE 不一定提升性能——某些版本的 PostgreSQL 会物化 CTE，反而增加 IO - 用
/*+ USE_INDEX */等提示强制走索引，只适合调试或兜底，线上慎用 - 窗口函数虽可替代部分相关子查询（如取每个用户的最新订单），但需确认是否支持排序稳定性（如
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time DESC)中create_time存在重复值时行为）
真正有效的优化路径不是“怎么写子查询”，而是“要不要让它存在”
多数百万级场景下，标量子查询不是语法问题，而是设计信号：它暴露了实时聚合与高频关联之间的矛盾。与其反复调优子查询，不如评估是否该把聚合结果提前物化。
- 稳定维度（如用户等级、地区归属）可建
MATERIALIZED VIEW（PostgreSQL）或定时刷新汇总表 - 高频 ID 列表（如黑名单、白名单）优先落地为带主键/索引的临时表，再
JOIN，别拼IN长列表 - 深度分页场景下，用延迟关联（
SELECT * FROM orders o INNER JOIN (SELECT id FROM orders ORDER BY create_time LIMIT 1000000,20) tmp ON o.id = tmp.id）绕过子查询，靠覆盖索引跳过回表
最常被忽略的一点：标量子查询性能崩塌往往和索引失效叠加爆发。查慢不是因为“数据多”，而是因为“每行都在做一次没索引的子查询”。先看 EXPLAIN，再动 SQL；先确认索引是否存在且被用上，再考虑重写逻辑。
