子查询中用count/sum配where易出错，需显式关联外层字段；存在性判断优先用exists；多状态求和宜用case when+sum；性能差时应检查执行计划并加索引。
子查询里用 COUNT 和 SUM 配 WHERE 容易出错
直接在子查询里写 COUNT(*) 或 SUM(column) 加 WHERE 条件，看似合理，但常因外层关联逻辑缺失导致结果全为 0 或重复计数。关键不是“能不能写”，而是“查哪张表、关联哪一列、是否去重”——子查询默认是独立执行的，不自动感知外层行上下文。
正确做法是让子查询能“看到”外层某字段（比如用户 ID），再按该字段过滤统计。典型结构是：(SELECT COUNT(*) FROM t2 WHERE t2.user_id = t1.id AND t2.status = 'done')。
- 必须显式写出关联条件（如
t2.user_id = t1.id），否则变成笛卡尔积或全表扫描 -
COUNT(*)统计行数，COUNT(column)会忽略 NULL；需要计非空值时别漏掉这点 - 如果外层有多条记录，每个子查询都单独执行一次，性能敏感场景要加索引（如
(user_id, status)联合索引）
用 EXISTS 替代 COUNT > 0 判断更高效
当只需要知道“是否存在满足条件的记录”（比如“该用户是否有已支付订单”），别写 (SELECT COUNT(*) FROM orders WHERE user_id = u.id AND paid = 1) > 0。数据库得扫完所有匹配行才返回数字，而 EXISTS 找到第一条就停。
等价但更快的写法是：EXISTS (SELECT 1 FROM orders WHERE user_id = u.id AND paid = 1)。
-
SELECT 1是惯用写法，内容无关紧要，数据库不取实际数据 - MySQL 8.0+ 和 PostgreSQL 对这类子查询有较好优化，但旧版本或复杂嵌套下仍建议用
EXISTS - 注意：不能把
EXISTS当成值参与计算（比如塞进SUM()），它只返回布尔逻辑
条件求和要用 CASE WHEN 套在 SUM 里，别放子查询外层
想算“每个用户的已发货订单金额总和”，错误写法是：(SELECT SUM(amount) FROM orders WHERE user_id = u.id AND status = 'shipped') —— 这本身没错，但若同时还要算“未发货金额”，重复写两个相似子查询，可读性和性能都差。
更清晰且通常更快的方式是在主查询的 SUM() 内部用 CASE WHEN 分流：
SELECT u.name, SUM(CASE WHEN o.status = 'shipped' THEN o.amount ELSE 0 END) AS shipped_sum, SUM(CASE WHEN o.status = 'pending' THEN o.amount ELSE 0 END) AS pending_sum FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id, u.name
- 避免多次关联同一张表，减少 I/O 和连接开销
-
ELSE 0必须写，否则CASE返回 NULL，SUM(NULL)会跳过该行（不是加 0） - 如果订单表数据量大且只关心特定状态，先在
JOIN条件里过滤（如ON u.id = o.user_id AND o.status IN ('shipped','pending')）能进一步提速
相关子查询性能差？先检查是否真需要逐行计算
带外层引用的子查询（如 SELECT ..., (SELECT COUNT(*) FROM log l WHERE l.user_id = u.id) FROM users u）在数据量大时容易变慢，因为每行都触发一次子查询执行。
- 先确认业务是否允许近似或延迟更新：比如用物化视图、定时汇总表替代实时子查询
- 如果必须实时，确保子查询中被关联的字段（如
log.user_id）有索引，且尽量缩小扫描范围（加时间范围、状态过滤） - 某些场景可用窗口函数替代，例如按用户分组后用
COUNT(*) OVER (PARTITION BY user_id)，但要注意是否需去重或条件限制
真正卡住的往往不是语法写法，而是没意识到子查询正在为每一行重复执行全表扫描——先看执行计划里的 DEPENDENT SUBQUERY 出现几次，再决定重构方向。
