用CASE WHEN将需忽略的值映射为统一占位符（如'other'或NULL）后再GROUP BY，SELECT/HAVING/ORDER BY中须同步使用该表达式；WHERE用于行级过滤，HAVING用于聚合后筛选。
GROUP BY 里怎么跳过某个值做聚合？
不能真“跳过”，GROUP BY 本身不支持条件性分组；必须靠 CASE WHEN 把要忽略的标识统一映射成同一个占位值（比如 NULL 或 'ignored'），再对这个新字段分组。
常见错误是直接在 WHERE 里过滤掉该标识——这会整行丢弃，不是“忽略标识后继续参与其他组的聚合”。比如想统计每个用户的订单数，但把 status = 'deleted' 的订单不算进总数、也不按其 user_id 分组，而是让它们彻底不参与任何聚合，那就该用 WHERE；但若想保留这些记录、只是不让它们影响分组键（例如把 category = 'temp' 的行归入“其他”类），就必须改写分组字段。
- 用
CASE WHEN category = 'temp' THEN 'other' ELSE category END替代原始字段参与GROUP BY - 注意：
SELECT列表、HAVING、ORDER BY中涉及分组字段的地方，都要同步用这个CASE表达式，否则报错或逻辑错乱 - 如果原字段有索引，这种写法会让索引失效，大数据量时得权衡是否加函数索引（如 PostgreSQL 的表达式索引）
WHERE 和 GROUP BY 配合时，哪些条件该放 WHERE，哪些该放 HAVING？
WHERE 过滤的是“行级原始数据”，HAVING 过滤的是“分组后的聚合结果”。想“忽略特定标识”再聚合，90% 的情况属于行级筛选——比如排除 type = 'test' 的记录，就该写在 WHERE 里，而不是等分完组再砍掉整个组。
典型误用：看到“要忽略某类数据”，就下意识把判断逻辑塞进 HAVING，结果发现没效果。因为 HAVING 只能引用聚合函数或 GROUP BY 字段，无法直接访问未聚合的原始列值（除非数据库支持非标准语法，如 MySQL 5.7 模式下允许）。
- 该放
WHERE：status != 'draft'、created_at >= '2024-01-01'、flag IS NOT NULL - 该放
HAVING：COUNT(*) > 10、AVG(amount) 、<code>MAX(updated_at) - 混合场景示例：
WHERE deleted = false AND type IN ('a', 'b') GROUP BY user_id HAVING SUM(amount) > 500
聚合时想动态屏蔽某个字段的值，但又不想丢数据——用 COALESCE + CASE 怎么写？
当需要“保留该行参与聚合，但让某个字段在分组/计算时不生效”，比如按 region 统计销售额，但 region = 'unknown' 的记录不应单独成组，而应合并到一个统一类别中，这时不能只靠 WHERE，得改造字段值。
COALESCE 本身不解决条件替换，真正起作用的是 CASE；COALESCE 仅适合处理 NULL 合并。更稳妥写法是显式 CASE，避免隐式类型转换出错。
- 正确：
CASE WHEN region = 'unknown' THEN 'unspecified' ELSE region END AS region_group - 错误（隐患大）：
COALESCE(NULLIF(region, 'unknown'), 'unspecified')—— 如果region是TEXT但'unspecified'被推断为UNKNOWN类型，某些数据库会报错 - 聚合函数内也可用：
SUM(CASE WHEN priority = 'low' THEN 0 ELSE amount END)，实现“低优先级不计入总和”
MySQL / PostgreSQL / SQLite 在这事上有什么关键差异？
核心逻辑一致，但细节容错度不同。最常踩的坑是 MySQL 的 ONLY_FULL_GROUP_BY 模式：开启时，SELECT 列表里所有非聚合字段都必须出现在 GROUP BY 中；而你用了 CASE 改写分组字段，却忘了同步改 SELECT 里的对应字段，就会报错。
PostgreSQL 最严格，不允许 SELECT 出现未分组也未聚合的列；SQLite 默认宽松，但启用 SQLITE_DBCONFIG_ENABLE_FKEY 等高级配置后行为可能变化。
- MySQL：检查
sql_mode是否含ONLY_FULL_GROUP_BY，线上环境大概率开启 - PostgreSQL：必须确保
SELECT、ORDER BY、HAVING中所有非聚合列，都和GROUP BY的表达式完全一致（字符级相同） - SQLite：虽允许“隐式分组”，但跨版本行为不稳定，建议始终显式写出分组表达式
复杂点在于：你以为在“忽略标识”，实际是在重定义分组语义。一旦涉及多个条件嵌套、NULL 处理、或需要和窗口函数联动，CASE 表达式很容易漏掉分支或类型不匹配——这时候光看执行结果不报错，不代表逻辑正确。
