最直接方法是在SELECT中用CASE WHEN一次性完成聚合计算与等级标签映射，避免在WHERE或GROUP BY中引用未生成的别名，并确保所有字段均为GROUP BY列或聚合结果。
用 CASE WHEN 基于聚合值打标签最直接
SQL 里没法“动态生成”变量或运行时逻辑，但可以用 CASE WHEN 在查询阶段就把聚合结果映射成等级标签。关键不是先算再判断，而是一次性在 SELECT 里完成计算+分类。
常见错误是试图在 WHERE 或 GROUP BY 里引用未定义的别名，比如写 WHERE alert_level = 'HIGH' —— 这会报错，因为 alert_level 是 SELECT 里才生成的，执行顺序上它还没出生。
- 必须把整个
CASE WHEN表达式写进SELECT，不能依赖别名做后续过滤 - 如果要按等级筛选，得把整条
CASE复制到HAVING（配合GROUP BY）或外层WHERE（配合子查询/CTE） - 边界值要明确：用
>=还是>？比如score > 90和score >= 90对 90 分的处理完全不同
GROUP BY 后加 CASE 需注意字段可见性
当聚合已发生（如统计每类订单的平均延迟），CASE 必须作用于聚合结果，不能引用原始行字段——否则会触发 SQL 错误，提示“nonaggregated column in SELECT list”。
例如想给每个产品线标等级：AVG(delay_hours) 是合法输入，但直接写 delay_hours 就不行。
- 所有出现在
CASE中的字段，要么是GROUP BY列，要么是聚合函数结果 - MySQL 5.7+ 默认开启
ONLY_FULL_GROUP_BY，会严格校验；PostgreSQL 和 SQL Server 更早就有类似约束 - 别用
SELECT *+CASE混搭，容易漏掉 GROUP BY 字段导致报错column must appear in the GROUP BY clause
避免嵌套过深导致可读性崩坏
三级以上 CASE WHEN 套嵌套会让 SQL 变成谜题，尤其当阈值随业务调整频繁时，维护成本陡增。更稳妥的做法是把等级规则抽成独立表或 CTE。
比如建一张 alert_thresholds 表存 level、min_value、max_value，再用 JOIN 关联聚合结果。这样改规则不用动主查询，DBA 也能快速验证。
- 单次查询中超过 4 个分支，建议拆出 CTE 或临时映射表
-
CASE里别混用数据类型：返回'LOW'、1、NULL会导致隐式转换，某些引擎会报inconsistent return types - 测试时务必覆盖边界值：刚好卡在
80、90的记录是否落入预期等级
窗口函数场景下标签逻辑要重写
如果用 ROW_NUMBER() 或 PERCENT_RANK() 做相对排名（比如“延迟最长的前 5% 订单标为 CRITICAL”），就不能套用普通 CASE 逻辑——因为窗口函数结果只能在 SELECT 和 ORDER BY 中使用，不能进 WHERE 或 GROUP BY。
典型翻车点：写 WHERE PERCENT_RANK() OVER(...) > 0.95，会报错说窗口函数不允许出现在 WHERE 子句。
- 必须用子查询或 CTE 先算出窗口值，再在外层用
CASE打标签 -
NTILE(20)比PERCENT_RANK更适合分段打标，但要注意空值和重复值会影响分桶均匀性 - 分区（
PARTITION BY）范围必须和业务语义一致：按region分还是按product_category分，结果差异极大
实际用的时候，最容易被忽略的是 NULL 处理——聚合结果可能是 NULL（比如某类数据全缺失），而 CASE WHEN x > 90 THEN 'HIGH' 对 x IS NULL 是不匹配的，会掉进 ELSE 或返回 NULL，这经常导致警报漏发。
