MySQL报错需补全GROUP BY或用MAX()/ANY_VALUE()；PostgreSQL等数据库必须显式聚合；主键分组宜用窗口函数；注意类型转换、NULL处理以及时区影响。
这不是 SQL 写错了，是数据库在拦你——它拒绝执行语义模糊的查询。
MySQL 报 Expression #1 of SELECT list is not in GROUP BY clause 怎么修
这是 ONLY_FULL_GROUP_BY 模式在起作用，不是语法问题，而是 MySQL 5.7+ 默认启用该模式，强制校验语义确定性。典型错误如：SELECT user_id, name, SUM(amount) FROM orders GROUP BY user_id，其中 name 既没进 GROUP BY，也没套聚合函数。
- 最稳妥做法：补全
GROUP BY，比如GROUP BY user_id, name——但前提是业务上user_id → name确实是确定关系（如外键关联主表） - 若无法补全（比如
name可能变更），改用MAX(name)或ANY_VALUE(name)；注意ANY_VALUE()不保证结果稳定，换执行计划可能返回不同值 - 禁用
ONLY_FULL_GROUP_BY属于绕过检查：临时可SET SESSION sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,...'，但生产环境不推荐——它掩盖了逻辑歧义，PostgreSQL/Oracle 根本不支持这个选项
PostgreSQL / SQL Server / Oracle 报 column must appear in GROUP BY clause 怎么处理
这些数据库没有 ANY_VALUE()，也不接受“随便取一个”，报错就是硬性拦截，没商量余地。
- 必须显式聚合或重构逻辑：
MAX(created_at)、STRING_AGG(status, ',')（PostgreSQL）、LISTAGG(status, ',')（Oracle） - 如果分组字段是主键（如
id），那整行其实都可确定——此时不该硬套GROUP BY，该用窗口函数：ROW_NUMBER() OVER (PARTITION BY id ORDER BY created_at DESC)标记最新记录后过滤 - 别用子查询“先 GROUP 再 JOIN 回原表”，容易漏数据、重复、难维护
GROUP BY 字段类型不匹配导致分组异常
看起来没报语法错，但结果为空或分组数不对，很可能是字段类型隐式转换捣鬼。
-
GROUP BY CAST(user_id AS CHAR)和GROUP BY user_id在某些引擎下被当作不同分组逻辑 - 所有
NULL在GROUP BY中被归为同一组，但如果你加了WHERE col IS NOT NULL却忘了这点，统计口径就偏了 - 按
DATE(created_at)分组时，TIMESTAMP存 UTC、DATETIME存本地时间，跨时区数据可能被切到不同日期
真正棘手的不是报错本身，而是你以为加个 MAX() 就解决了，结果发现业务上要的是“最新一条的 stat”——这时候得回头确认：到底是分组聚合，还是取最新明细？别让函数名带偏了问题本质。
