这是sql标准强制要求的语义一致性保障，数据库拒绝执行逻辑模糊的查询：非聚合列必须显式出现在group by中或包裹在聚合函数内，否则无法确定每组应返回哪一行的值。
GROUP BY报错“column must appear in GROUP BY clause”是语义问题，不是语法限制
这不是数据库故意卡你，而是它在拒绝执行一个逻辑上说不通的查询。比如写SELECT user_id, name FROM orders GROUP BY user_id，数据库看到的是：按user_id分组后，每组可能对应多个name（历史改名、多账号共用ID等），它没法决定该返回哪一行的name。报错不是bug，是标准SQL在逼你把业务意图写清楚。
MySQL 5.7+ 报 ERROR 1055 的真实原因
MySQL 5.7 默认启用 ONLY_FULL_GROUP_BY 模式，本质是跟 PostgreSQL / SQL Server / Oracle 对齐——它们从不妥协。报错信息里出现的 Expression #1 of SELECT list is not in GROUP BY clause，就是在告诉你：SELECT 列表里的第一个字段（比如name）既没进 GROUP BY，也没被MAX()MIN()ANY_VALUE()包住。
- 查当前模式：
SELECT @@sql_mode;，确认是否含ONLY_FULL_GROUP_BY - 别急着
SET sql_mode = ''关掉它——关了只是让错误消失，但结果依然不可靠 - 云数据库（如阿里云 RDS）通常不允许直接
SET GLOBAL，改配置得走控制台参数模板
把非聚合字段加进 GROUP BY 的实操陷阱
补全 GROUP BY user_id, name 看似简单，但容易踩坑：
-
name字段有空格、大小写混用或 NULL 值？GROUP BY会把它们各自分组，导致统计数虚高或漏数据 - 多表 JOIN 时，别用别名或表达式替代原始字段：
SELECT u.name AS n FROM users u GROUP BY n❌，必须写GROUP BY u.name - 时间字段如
created_at直接参与分组，跨时区可能把同一天的记录切到不同组；要用DATE(created_at)就得同步写进GROUP BY DATE(created_at) - 即使
user_id是主键，name理论上函数依赖于它，标准仍要求显式写出——数据库不推断业务关系，只认字段列表
想取“每组最新一条记录”，别硬套 GROUP BY
常见错误：SELECT order_id, MAX(updated_at), ANY_VALUE(status) ——ANY_VALUE(status) 不保证和 MAX(updated_at) 来自同一行。结果可能是最新时间配上周一的状态。
- 正确做法是窗口函数：
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC)，再WHERE rn = 1 - PostgreSQL 可用
LATERAL，BigQuery / Snowflake 支持QUALIFY，语义更直接 - 关联子查询也能做，但性能通常不如窗口函数，尤其大表
最易忽略的一点：只要 SELECT 里有非聚合字段又没放进 GROUP BY，就说明你还没想清楚“这一行结果到底代表什么”。数据库报错，是在给你留出修正语义的机会。
