GROUP BY中不能直接使用未命名的CASE WHEN表达式，必须在SELECT中显式命名并在GROUP BY中原样重复该表达式，或确保数据库版本支持别名引用；MySQL 5.7严格模式不支持别名，PostgreSQL等高版本可支持但兼容性差。
GROUP BY 里不能直接写 CASE WHEN 表达式，但可以复用它
多数数据库（如 PostgreSQL、SQL Server）允许在 SELECT 中定义 CASE WHEN 并用 AS 命名，然后在 GROUP BY 中直接引用别名；但 MySQL 5.7 严格模式或旧版本会报错 Unknown column 'level' in 'group statement'。最稳妥的做法是：在 GROUP BY 中**原样重复整个 CASE WHEN 表达式**，不依赖别名。
常见错误是只写 GROUP BY level 却没在 SELECT 里显式命名，或命名了但数据库不支持别名引用。调试时可先执行 SELECT id, CASE WHEN amount ，确认每行都有值再加 <code>GROUP BY。
- 别名引用仅在 MySQL 8.0+、PostgreSQL、SQL Server 中可靠；SQLite 和旧版 MySQL 必须重复表达式
- CTE 是更清晰的替代方案：
WITH grouped AS (SELECT ..., CASE WHEN ... END AS level) SELECT level, COUNT(*) FROM grouped GROUP BY level - 避免把
CASE WHEN写进WHERE——它在SELECT阶段才计算，WHERE看不见
漏写 ELSE 会让不匹配的数据全归进 NULL 组
CASE WHEN 没配 ELSE 时，默认返回 NULL；而 GROUP BY NULL 会把所有未覆盖的行（比如 amount 为 NULL、负数、超阈值）塞进同一组。现象是：总数对得上，但各分类加起来少了几百条——它们都在你看不见的 NULL 组里。
实操必须显式兜底：
- 业务上有“其他”含义，就写
ELSE 'other'或ELSE 'unknown' - 想排除异常值，应该用
WHERE过滤，而不是靠CASE不覆盖来隐式丢弃 - 数值区间推荐用
>=+而非 <code>BETWEEN，避免浮点误差或边界重叠 - 示例安全写法：
CASE WHEN amount
动态阈值不能拼字符串，得用参数化查询传入
SQL 本身不支持运行时“定义新分组逻辑”，但可通过应用层传参（如 @low_threshold）让 CASE WHEN 响应外部输入。直接拼接 SQL 字符串（如 'WHERE amount ）有注入风险，且不同数据库对参数占位符语法不一致（MySQL 用 <code>?，SQL Server 用 @p，PostgreSQL 用 ）。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
正确做法：
- 用数据库原生参数化机制，而非字符串拼接
- 阈值需做类型校验（比如确保
@low_threshold是 numeric，不是字符串'100 OR 1=1'） - 多档阈值（如 5 档）建议由应用层生成
CASE片段，避免硬编码在 SQL 里出错 - 固定宽度区间可用
FLOOR((amount - @min_val) / @step)，但要注意负数和空值处理
区间标签用整数比字符串更利于后续排序和聚合
用字符串分组（如 'low'/'mid'/'high'）看似直观，但字典序和业务顺序常不一致（'high' 排在 'low' 前面），后续做 ORDER BY 或累计求和时容易出错。
更稳妥的方式是返回整数档位编号：
- 左闭右开区间编号：
FLOOR((amount - @min_val) / @step) AS bucket_id - 自定义顺序映射：
CASE WHEN region = '华东' THEN 1 WHEN region = '华北' THEN 2 ELSE 3 END AS region_order - PostgreSQL 可用
width_bucket(amount, ARRAY[100,500,1000])替代手算，但 MySQL/SQL Server 不支持 - 若要用字符串描述区间，拼接时注意语义：例如
CONCAT(FLOOR(amount/100)*100, '-', FLOOR(amount/100)*100 + 99)，但得验证 0–99、100–199 是否符合业务
实际中真正麻烦的不是写对一条 SQL，而是当阈值从 2 个变成 8 个、区间从等宽变成非线性、还要兼容三套数据库时，CASE WHEN 的维护成本和边界判断一致性很容易被忽略。
