MySQL 5.7或更早版本中，相关子查询因缺乏物化能力会被重复执行，典型现象是EXPLAIN显示select_type为DEPENDENT SUBQUERY，外层每行触发一次内层全表扫描；应改写为LEFT JOIN聚合、窗口函数或CTE等方案，并确保关联字段有索引。
子查询被重复执行的典型现象
MySQL 5.7 或更早版本里，WHERE 条件中写 (SELECT COUNT(*) FROM orders WHERE user_id = u.id) 这类相关子查询时，如果外层扫描 10 万行用户，这个子查询就真会执行 10 万次——每次重新全表扫 orders。你查 EXPLAIN 会看到 select_type 是 DEPENDENT SUBQUERY，这就是危险信号。
不是所有子查询都这样：非相关子查询（比如 WHERE id IN (SELECT id FROM blacklist)）通常只执行一次；但只要子查询里引用了外层表字段，优化器就大概率无法重用结果。
改用 JOIN 替代相关子查询
这是最直接、最可控的解法。把“为每个用户统计订单数”这种需求，从子查询改成左连接聚合：
SELECT u.name, COALESCE(o.cnt, 0) AS order_count
FROM users u
LEFT JOIN (
SELECT user_id, COUNT(*) AS cnt
FROM orders
GROUP BY user_id
) o ON u.id = o.user_id;
关键点：
- 子查询提前按
user_id分组聚合，结果集变小，且只算一遍 -
LEFT JOIN避免丢失无订单用户 - 确保
orders.user_id有索引，否则内层GROUP BY仍可能慢
用窗口函数替代聚合子查询（MySQL 8.0+ / PostgreSQL）
如果只是想在原表基础上加一列统计值，不改变行数，窗口函数更简洁：
SELECT
u.*,
COUNT(o.id) OVER (PARTITION BY u.id) AS order_count
FROM users u
LEFT JOIN orders o ON u.id = o.user_id;
注意：
- 必须用
LEFT JOIN再套窗口，不能直接OVER (PARTITION BY u.id)而不关联orders，否则统计恒为 0 - 窗口函数不会减少数据量，但避免了多次执行子查询逻辑
- PostgreSQL 对
COUNT() OVER优化更好；MySQL 8.0 支持，但旧版不支持
临时表或 CTE 缓存中间结果（适合复杂逻辑）
当子查询逻辑复杂、多处复用（比如带多层嵌套、过滤、计算），硬塞进 JOIN 可读性差，这时可显式缓存：
WITH order_stats AS (
SELECT user_id, COUNT(*) AS cnt, AVG(amount) AS avg_amt
FROM orders
WHERE status = 'paid'
GROUP BY user_id
)
SELECT u.name, os.cnt, os.avg_amt
FROM users u
LEFT JOIN order_stats os ON u.id = os.user_id;
好处是逻辑隔离、便于调试；但要注意：
- CTE 在 MySQL 8.0+ 和 PostgreSQL 中默认物化（执行一次），但 SQLite 或某些老版本 MySQL 可能反复计算
- 如果
order_stats结果很大，CTE 物化本身有内存开销 - 真正要稳，可用
CREATE TEMPORARY TABLE显式建表并加索引
user_id 字段，再怎么改写 SQL，orders 表照样扫全表——先看执行计划里的 type 是不是 ref 或 range，再谈其他。 
