sum(case when)性能远优于相关子查询，因后者为外层每行重复全表扫描；需为orders.user_id建索引，避免在where中对索引字段用函数。
因为SUM(CASE WHEN)只扫描源表一次，而子查询聚合（尤其相关子查询）会为外层每一行重复执行全表或大范围扫描——性能差距不是几倍，而是线性放大到万倍级。
相关子查询触发重复计算
当子查询里带聚合且引用外层字段时（比如SELECT name, (SELECT COUNT(*) FROM orders WHERE user_id = users.id)），数据库必须为users表的每一行都重新跑一遍子查询。如果users有10万行，orders没索引，就是10万次全表扫描。
EXPLAIN里看到DEPENDENT SUBQUERY + type: ALL，基本就坐实了这个问题。
- 确保
orders.user_id有索引（最好是(user_id, status)联合索引，如果子查询还带状态过滤） - 避免在子查询WHERE中对索引字段用函数，比如
DATE(created_at) = '2024-01-01'→ 改成created_at >= '2024-01-01' AND created_at - MySQL 8.0.19+ 可加
/*+ MATERIALIZE */提示强制物化，但前提是子查询不包含隐式转换、函数或类型不一致
SUM(CASE WHEN)天然单次扫描
它把多个条件统计“压”进一个聚合流程：数据库读一行，同时判断所有CASE分支，分别累加到对应SUM桶里。整个过程只遍历源表一次。
但前提是WHERE先过滤——别让CASE去扛百万行。
- 写法上必须显式
ELSE 0，否则未匹配行贡献NULL，SUM直接跳过，结果偏小且难排查 - 多个
SUM(CASE WHEN)并列是安全的，但别在每个CASE里重复写相同计算，比如date_sub(current_date, 30)写了四遍 → 提前算好放进子查询 - 如果
CASE逻辑复杂（如多层阈值判断），优先拆到子查询打标，主查询只做SUM，避免表达式反复求值
聚合位置决定优化器能否下推条件
主查询里的GROUP BY + SUM(CASE)能利用索引顺序归并分组，甚至避免Using temporary；子查询里的GROUP BY则常被隔离处理，外层WHERE无法下推，导致聚合基数爆炸。
例如：SELECT user_id, COUNT(*) FROM orders WHERE status = 'paid' GROUP BY user_id能走(status, user_id)索引；但子查询(SELECT COUNT(*) FROM orders WHERE user_id = u.id AND status = 'paid')即使有同样索引，也可能因驱动顺序退化为全表扫。
- 子查询的
WHERE条件必须命中索引最左前缀，否则下推失败 - 别在子查询
GROUP BY里塞无业务意义的字段（比如id），它会让索引失效或强制排序 - 高频统计场景，宁可建临时表+索引，也别依赖嵌套子查询反复解析复杂逻辑
真正卡住性能的，往往不是CASE WHEN本身，而是它被放在了错误的位置——在子查询里做聚合，等于主动放弃优化器的下推能力；而在主查询里用SUM(CASE WHEN)，才是把数据库引擎的单次扫描优势真正用足。
