GROUP BY后SELECT列必须是聚合列或GROUP BY列，否则触发ERROR 1055；WHERE过滤行，HAVING过滤分组；多字段GROUP BY顺序影响索引与NULL处理；窗口函数可替代GROUP BY实现明细+统计。
GROUP BY 后 SELECT 列必须是聚合列或 GROUP BY 列
这是最常触发 ERROR 1055 的原因：MySQL 5.7+ 默认启用 sql_mode=ONLY_FULL_GROUP_BY，禁止在 SELECT 中引用未聚合、也未出现在 GROUP BY 中的列。
比如写 SELECT user_id, name, COUNT(*) FROM orders GROUP BY user_id，name 没聚合也没分组，直接报错。
- 正确做法：把
name加进GROUP BY，或用MAX(name)/MIN(name)显式聚合（前提是业务允许取极值） - 临时绕过：不推荐，但可执行
SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''))，仅用于调试 - 注意：PostgreSQL 和 SQL Server 更严格，连
MAX(name)都要求语义明确；SQLite 则默认宽松，容易掩盖逻辑问题
HAVING 和 WHERE 的分工不能混用
WHERE 过滤行，HAVING 过滤分组——这个边界一旦模糊，结果就容易错得悄无声息。
例如想查“订单数超 5 的用户”，写成 WHERE COUNT(*) > 5 会报错，因为 COUNT(*) 在 WHERE 阶段还没计算出来。
-
WHERE放原始字段条件：WHERE status = 'paid'（过滤单条订单） -
HAVING放聚合结果条件：HAVING COUNT(*) > 5（过滤分组后统计值） - 性能影响：先
WHERE再GROUP BY能显著减少分组数据量；反过来把条件塞进HAVING，等于全表分组完才筛，慢且浪费
多字段 GROUP BY 的顺序和 NULL 处理
写 GROUP BY a, b 不等于 GROUP BY b, a，虽然结果行数一样，但分组键的组合顺序会影响索引利用和排序行为。
更隐蔽的是 NULL：在大多数数据库中，NULL = NULL 为 false，但 GROUP BY 把所有 NULL 归为同一组——这和 ORDER BY 中 NULLS FIRST/LAST 的逻辑不一致，容易误判。
- 建索引时优先按
GROUP BY字段顺序创建复合索引，如INDEX idx_user_status (user_id, status)对GROUP BY user_id, status有效 - 若需区分
NULL和空字符串，提前用COALESCE(status, '_null_')转换，避免分组合并 - PostgreSQL 支持
GROUP BY a IS NOT NULL, a实现 NULL 单独成组，MySQL 不支持，得用CASE WHEN模拟
窗口函数替代 GROUP BY 的场景
当既要分组统计，又要保留原始明细行（比如每笔订单显示“该用户总消费额”），硬套 GROUP BY + JOIN 不仅啰嗦，还可能因多对一引发重复或丢失。
这时直接上窗口函数更干净：SUM(amount) OVER (PARTITION BY user_id) 就能原地算出每人总额，不改变行数。
- 兼容性：MySQL 8.0+、PostgreSQL 9.4+、SQL Server 2012+ 支持；老版本 MySQL 只能靠变量或自连接模拟，稳定性差
- 性能：窗口函数通常比
GROUP BY+JOIN快，尤其大数据量下，避免了中间结果物化 - 注意：
PARTITION BY语义等价于GROUP BY分组，但不能在同一个查询里同时用GROUP BY和窗口函数聚合同一字段，会报错
GROUP BY 看似简单，真正卡住人的往往是隐式行为：NULL 怎么分组、执行顺序怎么影响结果、不同数据库对标准的松紧程度。这些细节不跑真实数据很难暴露，光看文档容易漏掉。
