group by中必须显式写出与select中完全一致的case when表达式，不可用位置序号或别名；分组边界应统一采用左闭右开风格（如amount >= 100 and amount

GROUP BY 里必须写和 SELECT 中一模一样的 CASE WHEN 表达式

很多人在 SELECT 里写了 CASE WHEN amount ，却在 <code>GROUP BY 里只写 level 别名，结果在 PostgreSQL 或 MySQL 8.0+ 严格模式下直接报错。数据库不保证别名能在 GROUP BY 中被识别，尤其跨版本迁移时极容易翻车。

正确做法是把整个 CASE WHEN 表达式原样复制进 GROUP BY：

SELECT 
  CASE WHEN amount 

• 空格、换行、大小写都要一致——MySQL 5.7 在某些配置下会因空格差异判为不同表达式
• 别省略 ELSE 分支，否则 amount IS NULL 的行会被整行排除，总数对不上时第一个就查这个
• 如果字段是字符串类型但存数字（如 '95'），先 CAST(amount AS DECIMAL) 再比较，否则 PostgreSQL 会报错，MySQL 可能隐式转换但结果不可靠

WHERE 里不能用 CASE WHEN 定义分组逻辑

有人想在 WHERE 子句里写 CASE WHEN AVG(price) > 100 THEN 1 ELSE 0 END = 1 来“先筛出高均价品类”，这是无效的。因为 WHERE 执行阶段聚合还没发生，AVG(price) 根本不可见；就算换成单行字段，CASE 也会让条件变成非 SARGable，索引基本失效。

真正需要依赖全表统计值（比如“高于平均订单金额的客户”）做分组时，必须拆成两步：

• 用子查询或 CTE 先算出基准值：例如 (SELECT AVG(amount) FROM orders)
• 再在外部查询中用该值参与 CASE WHEN 判断，并放进 GROUP BY
• 避免在 HAVING 里重构分组——它只能过滤已形成的组，不能定义新维度

区间边界顺序和风格必须统一

用 BETWEEN 100 AND 999 和 >= 100 混搭，容易漏掉 100 或重复计算。更危险的是写成 amount >= 100 和 amount > 100 并列，100 就只进前一个分支（MySQL）或根本无法确定（PG）。

推荐全部采用「左闭右开」风格，显式控制边界：

• amount
• amount >= 100 AND amount
• amount >= 1000

这样既避免重叠，也防止遗漏，还能让执行计划更容易下推索引。

跨数据库兼容写法要收敛到标准 SQL

MySQL 允许 SELECT CASE... , COUNT(*) GROUP BY 1 这种位置序号写法，PostgreSQL 不支持；MySQL 对 NULL = NULL 有宽松处理，PG 要求必须用 IS NULL。一旦脚本要跑在多个环境上，就得放弃方言特性。

安全做法是：

• 所有分组表达式显式写出，不用别名、不用位置序号
• NULL 判断统一用 IS NULL / IS NOT NULL
• 字符串转数字一律加 CAST(... AS ...)，不依赖隐式转换
• 测试时用最小数据集验证分组总数是否等于原始表 COUNT(*)，这是最快速的合理性检查

动态分组真正的复杂点不在语法，而在边界语义是否和业务口径完全对齐——比如“中额”到底包不包括 100，“大额”是否含零单客户。这些必须和产品、BI 同步确认，代码只是忠实落地。