应优先用count(case when...then 1 end)实现分组内多条件计数，因其天然忽略null，无需显式else；漏写else时sum会致整列变null而漏统，且count语义更契合“存在即计1”需求。
用CASE WHEN做分组内多条件计数时，别直接套SUM(CASE...)
直接写 SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) 看似没问题，但遇到 NULL 值会出错：如果 status 允许为 NULL，ELSE 0 虽能兜底，但一旦漏写 ELSE，整列就变 NULL，聚合后该行统计直接消失。更稳妥的是用 COUNT(CASE WHEN status = 'paid' THEN 1 END) —— COUNT 天然忽略 NULL，不用显式补 0。
常见错误现象：COUNT(*) 和 COUNT(CASE...) 结果对不上，往往就是 CASE 分支没覆盖全、又没写 ELSE 导致部分行返回 NULL，被 COUNT 忽略了。
- 需要“存在即计 1”语义时，优先用
COUNT(CASE WHEN ... THEN 1 END) - 需要加权求和（比如不同状态对应不同积分）才用
SUM(CASE WHEN ... THEN score END) - 所有分支必须逻辑互斥，否则同一行可能命中多个 WHEN，结果取决于书写顺序
在GROUP BY里混用多个CASE WHEN字段，注意NULL值分组行为
当写 GROUP BY region, CASE WHEN age >= 60 THEN 'senior' WHEN age >= 18 THEN 'adult' ELSE 'minor' END，如果 age 是 NULL，整个 CASE 表达式结果也是 NULL，而 SQL 标准中 NULL = NULL 不成立，所以所有 age 为 NULL 的记录会被归到同一个隐式分组（多数引擎如 PostgreSQL、MySQL 8.0+ 会把它们聚在一起；但 SQLite 行为不一致）。这容易造成“明明数据有空值，却看不到对应分组”的困惑。
使用场景：做用户分层报表时，若原始数据含大量缺失年龄，应显式处理 NULL：
- 加一个分支：
CASE WHEN age IS NULL THEN 'unknown' WHEN age >= 60 THEN 'senior' ... END - 或提前过滤：
WHERE age IS NOT NULL（如果业务允许） - 避免把 CASE 表达式直接丢进 GROUP BY 而不检查其 NULL 概率
嵌套CASE WHEN导致可读性崩坏，用CTE拆解更易维护
当统计逻辑涉及“按渠道分类 → 再按下单时间判断新老客 → 再按支付状态打标签”，三层嵌套 CASE WHEN (CASE WHEN ... THEN (CASE WHEN ...)) 会让 SQL 变成天书，而且调试时无法单独验证中间层逻辑。
性能影响不大，但可维护性极差。正确做法是用 CTE 把每层抽象出来：
WITH labeled_orders AS (
SELECT *,
CASE WHEN channel IN ('wechat', 'alipay') THEN 'mobile'
WHEN channel = 'web' THEN 'desktop'
ELSE 'other' END AS channel_type,
CASE WHEN order_time <p>这样每一层职责清晰，改渠道分类逻辑只动第一个 CTE，不影响后续聚合。</p><h3>MySQL 5.7 下用CASE WHEN做条件聚合，小心隐式类型转换陷阱</h3><p>MySQL 在 <code>CASE WHEN</code> 中若分支返回不同类型（比如有的分支是字符串 <code>'high'</code>，有的是数字 <code>100</code>），会尝试隐式转成同一类型——通常是转成浮点或字符串，导致数值比较失效或排序错乱。例如：</p><p><code>CASE WHEN amount > 1000 THEN 'high' ELSE amount END</code>，当 <code>amount</code> 是 DECIMAL，整个表达式可能变成 DOUBLE，再用于 <code>GROUP BY</code> 就可能因精度问题把本该同组的值拆开。</p>
- 统一返回类型：全部用字符串，或全部用数值（配合
CAST） - 避免混用：
CASE WHEN amount > 1000 THEN 'high' ELSE CAST(amount AS CHAR) END - MySQL 5.7 不支持
IFNULL在聚合上下文中完全替代 CASE，别偷懒
多维度聚合本身不难，难的是每个 CASE 分支的边界是否真覆盖了全集、NULL 是否被显式接纳、类型是否真正一致——这些地方一松懈，统计结果就悄悄偏了。
