标量子查询越嵌越慢是因为每行都重新执行一次，无法复用结果；三层嵌套超出优化器推导能力，导致N×M级重复解析与扫描，应改用CTE预聚合、窗口函数或LATERAL JOIN替代。
标量子查询在SELECT中为何越嵌越慢
因为每行都重新执行一次，数据库无法复用结果。比如 SELECT name, (SELECT COUNT(*) FROM orders WHERE user_id = u.id AND status = (SELECT 'shipped' FROM dual)) 这种写法，最内层子查询看似常量，但优化器未必能识别为“可提升（lifted）”，仍可能对每一行重复解析、绑定、执行——CPU花在计划重编译和上下文切换上，而不是算数据。
两层以内可保留，三层必须拆
标量子查询嵌套超过两层（主查询 → SELECT 中子查询 → 该子查询里再套一个 SELECT），基本已超出优化器合理推导范围。此时执行计划里大概率出现多个 Compute Scalar 节点，且外层行数 × 内层扫描成本呈线性甚至指数增长。
- 允许的写法：
(SELECT AVG(score) FROM scores s2 WHERE s2.class_id = s1.class_id)（一层关联） - 危险写法：
(SELECT COUNT(*) FROM logs l WHERE l.user_id = u.id AND l.type IN (SELECT t.code FROM log_types t WHERE t.category = (SELECT c.id FROM categories c WHERE c.name = 'error')))（三层） - 替代方案：把最内两层提前聚合进 CTE，或用
LATERAL JOIN（PostgreSQL/SQL Server 2022+）显式控制执行顺序
用窗口函数或预聚合JOIN替代标量子查询
标量子查询本质是“按行求聚合”，而窗口函数或 GROUP BY + JOIN 是“按组求聚合再对齐”，后者只需一次扫描、一次哈希匹配，避免 N 次重复计算。
- 坏例子：
SELECT id, name, (SELECT MAX(created_at) FROM events e WHERE e.user_id = u.id) AS last_event - 好做法：先
WITH user_last AS (SELECT user_id, MAX(created_at) AS last_event FROM events GROUP BY user_id)，再JOIN user_last ON user_last.user_id = u.id - 更优（若支持）：
MAX(created_at) OVER (PARTITION BY user_id)—— 零 JOIN、零临时表、无重复扫描
别忽略索引与执行计划验证
即使你把标量子查询改成了 JOIN 或窗口函数，如果关联字段没索引，照样会退化成全表扫描。关键不是“有没有嵌套”，而是“执行路径是否走索引”。
- 必查执行计划中子查询部分是否显示
Index Seek或Index Range Scan；若为Table Scan或Clustered Index Scan，立刻加索引 - 特别注意：MySQL 8.0+ 对标量子查询有自动消除（subquery unnesting）能力，但仅当子查询不带相关列、且优化器判定收益大于开销时才触发——不能依赖，必须看
EXPLAIN FORMAT=TREE输出 - 金仓 V009R002C014+、SQL Server 2022+ 支持
APPLY和LATERAL，语义清晰且更容易命中索引，但需确认目标版本是否启用对应优化开关
