应补全GROUP BY子句或改用窗口函数；若分组字段为主键，用ROW_NUMBER()等窗口函数确保明细字段与聚合结果同源，避免语义歧义。
MySQL报错“Expression #1 of SELECT list is not in GROUP BY clause”怎么修
这是ONLY_FULL_GROUP_BY在起作用，不是SQL写错了，而是数据库在拦你——它拒绝执行语义模糊的查询。比如SELECT user_id, name, SUM(amount) FROM orders GROUP BY user_id，name既没进GROUP BY，也没套聚合函数，MySQL 5.7+ 就直接报错。
最稳妥的做法是补全GROUP BY：把所有非聚合字段都加进去，例如GROUP BY user_id, name。前提是业务上user_id → name确实是确定关系（比如外键关联主表）；否则，用MAX(name)或ANY_VALUE(name)也行，但注意ANY_VALUE()不保证结果稳定，换执行计划可能返回不同值。
禁用ONLY_FULL_GROUP_BY属于绕过检查：临时改用SET sql_mode = 'STRICT_TRANS_TABLES,...'（去掉ONLY_FULL_GROUP_BY），永久改要编辑my.cnf并重启 MySQL。但生产环境不推荐——它掩盖了逻辑歧义，其他数据库（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字段类型不匹配或NULL导致分组异常
字符串和数字混用、NULL处理差异、时区字段（如TIMESTAMP vs DATETIME）都可能让分组结果出人意料。
常见坑：
-
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存本地时间，跨时区数据可能被切到不同日期
什么时候该放弃GROUP BY，改用窗口函数
当你需要“每组一条结果 + 原始明细字段”时，硬套GROUP BY极易掉坑。比如查“每个用户的最新订单 + 订单金额 + 用户姓名”，用GROUP BY user_id根本没法同时保证name和amount来自同一条记录。
正确路径是窗口函数：
-
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time DESC)标记每组最新记录 - 外层
WHERE rn = 1过滤，确保字段来自同一行 - 这种写法跨数据库兼容性好（除早期MySQL外），语义清晰，性能通常也优于多层JOIN或子查询
真正难的不是写对语法，而是判断哪一列的值必须和聚合结果来自同一行——这个业务约束，数据库不会替你猜。
