子查询中用COUNT(*)或SUM()变慢，因数据库无法复用外层索引，需反复扫描聚合；建议改写为LEFT JOIN+GROUP BY，并确保关联字段有索引。
子查询里用 COUNT(*) 或 SUM() 计算字段为什么变慢
因为数据库无法有效复用外层查询的索引，每次执行子查询都要独立扫描、聚合，尤其当外层结果集大时，子查询会被反复执行多次。比如 SELECT id, (SELECT COUNT(*) FROM orders WHERE user_id = t.id) AS order_cnt FROM users t，若 users 有 10 万行，orders 表可能被扫描 10 万次。
实操建议：
- 优先改写为
LEFT JOIN+GROUP BY，让聚合只做一次：SELECT u.id, COALESCE(o.order_cnt, 0) AS order_cnt FROM users u LEFT JOIN (SELECT user_id, COUNT(*) AS order_cnt FROM orders GROUP BY user_id) o ON u.id = o.user_id
- 确保子查询中涉及的关联字段（如
user_id）有索引，否则GROUP BY和JOIN都会退化 - 避免在子查询中使用
ORDER BY或LIMIT——它们不仅无意义，还会阻止优化器下推条件
WHERE 条件里嵌套子查询带表达式导致全表扫描
像 WHERE status = (SELECT UPPER('active')) 看似简单，但某些数据库（如 MySQL 5.7 前）会把整个子查询当作不可下推的“黑盒”，放弃使用 status 字段上的索引。
实操建议：
- 把常量表达式提前计算好，直接写进主查询：
WHERE status = 'ACTIVE'，而不是依赖子查询运行时求值 - 如果表达式必须动态计算（比如基于另一张配置表），用
JOIN替代子查询，并确保连接字段有索引 - PostgreSQL 中可考虑用
LATERAL子查询替代相关子查询，它支持更早绑定外层变量，有利于计划重用
子查询返回多列或多行却没加 EXISTS 或 IN 限定，引发错误或隐式截断
常见错误现象：WHERE id = (SELECT user_id FROM logs WHERE time > NOW() - INTERVAL '1 day')，如果日志当天有多条记录，MySQL 报错 Subquery returns more than 1 row，而 PostgreSQL 可能静默取第一行，行为不一致。
实操建议：
- 明确语义：要判断存在性，就用
EXISTS；要匹配集合，就用IN；要取单值，必须加LIMIT 1并确认业务允许丢弃多余结果 -
IN子查询中若含NULL，整个条件可能变为UNKNOWN（SQL 三值逻辑），导致意外过滤掉数据，可用IN (...) OR ... IS NULL显式补全 - 别在子查询里写
SELECT *——哪怕只是临时调试，也容易因字段增减引发主查询列数错配
用窗口函数替代子查询计算字段，但忘了分区或排序影响结果
比如想给每个用户最新订单打标，写成 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) 是对的；但如果漏了 PARTITION BY，就会把全表订单排一个序，结果完全错位。
实操建议：
- 窗口函数不是万能替代：它不能跨分组引用其他行的聚合结果（比如“本用户订单数 / 全站平均订单数”），这种仍需先聚合再
JOIN - 注意
ORDER BY在窗口定义中的必要性——没有它，ROW_NUMBER()和RANK()结果不确定，LAG()/LEAD()无法保证顺序 - 某些旧版 MySQL（
复杂点在于：子查询性能问题很少是单一原因，往往是索引缺失 + 写法不当 + 统计信息过期三者叠加。最容易被忽略的是执行计划里那个不起眼的 DEPENDENT SUBQUERY 标记——它意味着子查询被反复执行，而不是你想象中的一次预计算。
