GROUP BY报错因非聚合字段未出现在GROUP BY中；正确写法是所有非聚合列均需加入GROUP BY，或用聚合函数包裹，如MAX(batch_no)；COUNT(quantity)不等价于统计正库存SKU数，应使用COUNT(CASE WHEN quantity>0 THEN 1 END)。
GROUP BY 为什么一用就报错：缺少聚合字段
写 SELECT product_id, SUM(quantity) FROM inventory GROUP BY product_id 没问题，但一旦多加一个没参与聚合也没出现在 GROUP BY 的字段（比如 warehouse），MySQL 会直接报 Expression #2 of SELECT list is not in GROUP BY clause。这不是你写错了，是 SQL 标准在较真——它要求所有非聚合列必须明确属于分组依据。
常见错误场景：想查每个商品在各仓的总库存，却写成 SELECT product_id, warehouse, SUM(quantity) 而没把 warehouse 加进 GROUP BY；或者想顺手带出最新入库时间，用了 MAX(created_at) 却忘了 created_at 本身不能直接选。
- 正确做法：所有非聚合字段都得出现在
GROUP BY后面，例如按商品+仓库汇总：GROUP BY product_id, warehouse - 想“附带”某个值（如最新批次号）？改用聚合函数：
MAX(batch_no)或ANY_VALUE(batch_no)（MySQL 5.7+），别直接写batch_no - PostgreSQL 更严格，连
ANY_VALUE()都不支持，必须老实用聚合函数包裹
SUM 和 COUNT 区别太大，别混着用算“有货数”
盘点常要两个数：总库存量（SUM(quantity)）和“有多少个 SKU 有正库存”（即 COUNT 统计行数）。但新手容易写成 COUNT(quantity)，结果发现它统计的是 quantity IS NOT NULL 的行数，不是“数量 > 0”的行数。
典型误用：想统计当前有多少种商品还剩货，却得到比实际更多的数字，因为有些 quantity 是 0 或负数（比如已预约未出库），但它们依然被 COUNT(quantity) 算进去了。
- 要统计“有正库存的 SKU 数量”，用：
COUNT(CASE WHEN quantity > 0 THEN 1 END)或SUM(CASE WHEN quantity > 0 THEN 1 ELSE 0 END) -
COUNT(*)统计所有行（含quantity = 0或NULL）；COUNT(quantity)只跳过NULL，不跳过 0 - 如果表里存在逻辑删除（
is_deleted = 1），记得在WHERE里过滤掉，否则COUNT(*)会虚高
WHERE 和 HAVING 不是一个东西，过滤时机完全不同
想筛出“总库存小于 10 的商品”，很多人会写 WHERE SUM(quantity) ，然后收到语法错误：聚合函数不能用在 WHERE 里。因为 WHERE 在分组前执行，而 SUM() 是分组后才有的结果。
真实流程是：先 WHERE 过滤原始行（比如只看 status = 'active' 的记录），再分组，最后用 HAVING 对分组结果做条件筛选。
- 过滤单行数据（如状态、日期范围、仓库编码）→ 用
WHERE - 过滤分组后的聚合结果（如
SUM(quantity) 、COUNT(*) > 1）→ 必须用HAVING -
HAVING性能敏感：它作用于已经分组的结果集，如果WHERE没提前缩小数据量，HAVING就得处理大量无意义分组
GROUP BY 多字段时顺序影响索引命中
如果经常按 warehouse, product_id 分组查各仓库存，但表上只有 (product_id, warehouse) 的联合索引，那这个索引大概率不会被用于加速 GROUP BY。MySQL 的 B+ 树索引对多列排序是“最左前缀”生效的，GROUP BY 的字段顺序最好和索引定义顺序一致。
更隐蔽的问题：即使加了正确索引，如果 SELECT 里包含没索引的字段（比如 product_name），MySQL 可能放弃使用索引而走临时表 + filesort，导致慢查询。
- 检查执行计划：用
EXPLAIN看type是否为index或range，避免出现ALL或using temporary; using filesort - 索引建议：按高频
GROUP BY字段顺序建联合索引，例如常用GROUP BY warehouse, product_id，就建INDEX idx_warehouse_pid (warehouse, product_id) - 如果还要返回
product_name，要么把它加入索引（覆盖索引），要么接受回表——但别指望靠GROUP BY自动优化这个
GROUP BY 看似简单，真正卡住人的地方往往不在语法，而在“哪一步该过滤”“哪个字段该进 GROUP BY”“索引到底有没有被用上”。尤其当库存表带历史快照、跨仓调拨、负库存等业务细节时，一个 ANY_VALUE() 或漏写的 WHERE 条件，就能让盘点结果差几万件。
