不能只靠 GROUP BY 得出“哪些产品已预警”，必须在聚合前或聚合中用 CASE WHEN 判断 stock 与 min_stock 关系，再统计三类数量。
用 CASE WHEN 在 GROUP BY 后做库存预警分类统计
直接说结论：不能只靠 GROUP BY 得出“哪些产品已预警”，得在聚合前或聚合中嵌入条件判断。否则你只会得到每个产品的总库存，而不是“是否低于阈值”的状态。
典型场景是：有一张 products 表，含 product_id、stock、min_stock（安全库存），要统计“缺货”“临界”“正常”三类产品的数量。
常见错误是先 GROUP BY product_id 再想在外面加 WHERE stock —— 这只能筛出行，没法统计分类总数。
- 正确做法是在
SELECT里用CASE WHEN stock 生成分类标签 - 再对这个标签
GROUP BY，才能统计每类多少个产品 - 注意：
CASE必须写在SELECT列表里，且GROUP BY要引用它（或用列序号，但不推荐）
SELECT
CASE
WHEN stock < min_stock THEN '缺货'
WHEN stock <= min_stock * 1.5 THEN '临界'
ELSE '正常'
END AS alert_level,
COUNT(*) AS product_count
FROM products
GROUP BY
CASE
WHEN stock < min_stock THEN '缺货'
WHEN stock <= min_stock * 1.5 THEN '临界'
ELSE '正常'
END;避免 GROUP BY 和 WHERE 混用导致漏统计
有人会先用 WHERE stock 筛出缺货产品，再 <code>GROUP BY —— 这样只能看到缺货的，其他两类直接消失。预警统计必须覆盖全量，否则“正常”类产品数就是 0，不是真为 0。
另一个坑是把判断逻辑放到 HAVING 里，比如 HAVING SUM(stock) 。这会按组聚合后过滤组，但你根本不需要“所有产品总库存是否不足”，而是每个产品独立判断。
-
WHERE是行级过滤，用在聚合前；HAVING是组级过滤，用在聚合后 - 库存预警是单行判断（每个产品自己和自己的
min_stock比），不是跨行聚合逻辑 - 如果表里有多个仓库的记录（即同一
product_id多行），得先按产品聚合出总库存，再判断——这时才需要两层：子查询或 CTE 先SUM(stock) GROUP BY product_id，外层再CASE
MySQL / PostgreSQL / SQL Server 对 CASE + GROUP BY 的兼容性差异
绝大多数主流数据库都支持在 SELECT 和 GROUP BY 中写相同 CASE 表达式，但细节有差别：
- MySQL 8.0+ 和 PostgreSQL 允许直接
GROUP BY alert_level（别名），只要alert_level来自CASE - SQL Server 和旧版 MySQL 要求
GROUP BY写完整表达式，不能只写别名，否则报错Column 'xxx' is invalid in the select list - SQLite 严格要求
GROUP BY的字段必须出现在SELECT中，且不支持别名引用，也得写重复的CASE
所以最稳妥的写法是：显式写出 CASE 表达式两次（SELECT 一次，GROUP BY 一次），不依赖别名。
性能注意：别在 CASE 里调用函数或子查询
如果预警逻辑复杂，比如要查最近一次入库时间、或关联销售表算 7 天销量，千万别把这些塞进 CASE WHEN 里——那会导致每行都执行一次子查询，数据量大时直接卡死。
- 复杂判断一律前置：用 CTE 或子查询先算出每个产品的
current_stock、is_low等布尔字段 - 再对这个中间结果做
CASE+GROUP BY - 索引能帮上忙的地方：确保
stock和min_stock字段有单独索引或组合索引，尤其当表很大且只查预警产品时
预警统计看着简单，但一旦涉及多源数据聚合、动态阈值或历史趋势，就很容易从一行 CASE 滑向嵌套子查询地狱。先想清楚判断依据是单表字段，还是必须跨表/跨时间计算——这个分水岭决定了整条 SQL 的结构。
