是的，标量子查询中COUNT()会被多次执行；当外层查询返回N行，且子查询相关时，数据库通常对每行执行一次COUNT()，形成O(N×M)复杂度，性能远低于先GROUP BY再LEFT JOIN的集合式处理。
标量子查询里用 COUNT(*) 被执行多次？这是真的
只要标量子查询出现在 SELECT 列表或 WHERE 子句中，且外层查询返回多行，数据库（尤其是 PostgreSQL、SQL Server）很可能对每个外行都重新执行一次子查询。比如：
SELECT id, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS order_count FROM users u;
当 users 有 1000 行，COUNT(*) 就可能跑 1000 次——哪怕所有用户订单数据都缓存在内存里。
用 LEFT JOIN + GROUP BY 替代最稳妥
把聚合逻辑提前到 FROM 子句，避免逐行触发。关键点是：先聚合，再关联，不带条件的子查询变成显式连接：
- 聚合表必须用
GROUP BY明确分组键（如user_id），否则会合并成单行 - 必须用
LEFT JOIN，否则没有订单的用户会被丢掉（而原标量子查询会返回0） - 聚合结果列直接引用，不再嵌套，避免优化器“看不懂”
改写后：
SELECT u.id, COALESCE(o.order_count, 0) AS order_count FROM users u LEFT JOIN ( SELECT user_id, COUNT(*) AS order_count FROM orders GROUP BY user_id ) o ON o.user_id = u.id;
LATERAL 在 PostgreSQL 里能保留逻辑但需谨慎
PostgreSQL 支持 LATERAL，语义上更接近原标量子查询，但它不是万能加速器：
-
LATERAL子查询仍按外行逐次执行，但允许引用外层列，且优化器有时能物化中间结果 - 仅当子查询含复杂过滤或依赖外层计算（如
WHERE status IN (SELECT ...)）时才比JOIN更自然 - 如果只是简单
COUNT(*)或MAX(created_at)，LATERAL通常比等价的JOIN慢，因为少了一层提前分组剪枝机会
示例（不推荐用于纯计数）：
SELECT u.id, l.order_count FROM users u, LATERAL (SELECT COUNT(*) AS order_count FROM orders o WHERE o.user_id = u.id) l;
MySQL 8.0+ 可用 CTE + WINDOW，但别滥用
MySQL 不支持标量子查询物化，但 CTE 配合窗口函数可绕过部分重复计算场景：
- 适用于需要同一批数据上多个聚合维度（如同时要
COUNT和AVG(amount)） -
WINDOW必须基于同一PARTITION BY，否则仍会多次扫描 - CTE 本身不保证物化（MySQL 8.0 默认不物化 CTE），加
/*+ MATERIALIZE */提示才强制落地
示例（仅当真需要多聚合时考虑）：
WITH order_agg AS ( SELECT user_id, COUNT(*) AS cnt, AVG(amount) AS avg_amt FROM orders GROUP BY user_id ) SELECT u.id, COALESCE(o.cnt, 0), COALESCE(o.avg_amt, 0) FROM users u LEFT JOIN order_agg o ON o.user_id = u.id;
实际性能差异往往取决于数据分布和索引。最常被忽略的是：没给 orders.user_id 加索引，那无论怎么改写，每次子查询都得全表扫。
