标量子查询性能差因每行触发独立执行，复杂度O(N×M)；改JOIN易错在NULL处理、多行报错丢失、空组聚合口径；极小不相关子查询、需短路语义或强依赖逐行求值时应保留。
因为这种写法会让数据库对主表每行都重复执行一次子查询，10 万行就是 10 万次独立查询，性能直接线性崩塌。
标量子查询会触发嵌套循环执行
SELECT 列表里的子查询（比如 (SELECT MAX(order_time) FROM orders WHERE user_id = u.id)）是标量子查询，MySQL/PostgreSQL 都无法提前物化结果，只能等外层扫描到某一行时，才去执行一次内层查询。这不是“优化器没尽力”，而是语义决定的：它必须保证每行返回值都基于当前行的关联条件实时计算。
- EXPLAIN 中会出现
DEPENDENT SUBQUERY或SubPlan节点，且右侧常带Seq Scan或重复Index Scan - 哪怕
orders.user_id有索引，也只加速单次查找，不减少调用次数 - 总时间复杂度是
O(N × M)，不是O(N + M)—— 这是本质区别
改写为 JOIN 容易踩的三个坑
把 SELECT u.name, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) 改成 LEFT JOIN ... GROUP BY 是常规解法，但实际落地常出错：
-
NULL处理不一致：原写法无订单时返回NULL，JOIN 后若没写COALESCE(COUNT(o.id), 0)，COUNT本身不会返回NULL，但其他聚合如AVG()会，边界行为要对齐 - 多行报错机制丢失：标量子查询遇到重复匹配会立刻报
ERROR: more than one row returned by a subquery used as an expression；JOIN 却静默产生笛卡尔积，结果污染难发现 - 空组聚合口径混乱：比如原写法用
(SELECT AVG(amount) FROM payments WHERE user_id = u.id)，空时返回NULL；而LEFT JOIN后直接AVG(p.amount)在空组中也返回NULL，看似一致，但若混用SUM/COUNT就可能漏掉COALESCE导致业务逻辑偏差
哪些场景下子查询反而更安全？
不是所有子查询都要消灭。以下情况保留子查询更稳妥：
- 子查询结果集极小且稳定，比如
(SELECT config_value FROM sys_config WHERE key = 'timeout')—— 不相关、单行、无关联字段，优化器会拉起为InitPlan执行一次 - 需要短路语义：比如
WHERE EXISTS (SELECT 1 FROM audit_log WHERE user_id = u.id AND status = 'blocked')，EXISTS可在找到第一行就终止，比LEFT JOIN+IS NOT NULL更早退出 - 业务逻辑强依赖“逐行求值”语义，例如权限校验中需对每个用户单独查 RBAC 规则表，且规则表本身有行级动态条件（如生效时间、环境标签），JOIN 难以复现等价逻辑
最危险的不是语法错误，而是改写后行为微变却长期不暴露——比如统计报表里少计了 0.3% 的空用户订单数，上线两周才被财务对账发现。
