MySQL ONLY_FULL_GROUP_BY 报错原理与 SQL 改写指南-代码聚汇网

MySQL ONLY_FULL_GROUP_BY 报错原理与 SQL 改写指南

MySQLsql_modeONLY_FULL_GROUP_BY

|难度：普通|阅读约 38 分钟

接手老项目最怕的就是“之前跑得好好的 SQL，一升级环境就崩了”。朋友公司从 MySQL 5.6 升到 5.7，上线当晚监控就开始刷屏，后台订单查询接口大面积报 1055 错误。一开始大家都以为是数据问题，结果所有报错里都带着同一句话：this is incompatible with sql_mode=only_full_group_by。这不是业务逻辑变了，也不是数据脏了，而是 MySQL 把一个默认行为从“关闭”切成了“开启”。如果你还没搞懂这个模式，迟早会在某次上线或者换库的时候被它上一课。

ONLY_FULL_GROUP_BY 是 MySQL 的 sql_mode 里的一个开关，它约束的是 GROUP BY 分组查询的合法性。很多人第一次接触它是在报错排查时，但真正理解它的判定规则、适用边界和修改代价的人不多。这篇文章我会从一次升级事故讲起，把它的原理、判定规则、常见报错场景、SQL 改写方案、以及什么时候能改 sql_mode 讲透。

1. 为什么好好的 SQL 换个环境就报 1055？从一次升级事故说起

1.1 一个能稳定复现的报错现场

先看一条非常典型的“历史遗留” SQL，在 5.6 时代它运行得毫无波澜：

sql复制SELECT
    user_id,
    user_name,
    MAX(order_amount) AS max_amount
FROM orders
GROUP BY user_id;

这条 SQL 的意图很直观：查出每个用户的最高订单金额，顺便把用户名带出来。在 MySQL 5.6 及更早版本中，默认 sql_mode 是空的，GROUP BY 机制走的是“宽松模式”，MySQL 会允许 SELECT 列表里出现那些既不在 GROUP BY 中、也没有被聚合函数包裹的列，比如这里的 user_name。当 user_id 相同的一批订单里出现多个不同 user_name 时，MySQL 会默默从中挑一个返回，完全不报错。

到了 5.7.5 及之后，MySQL 默认开启了 ONLY_FULL_GROUP_BY，同样的 SQL 执行计划都没走到就开始报错：

text复制ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'orders.user_name' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

1.2 三层环境为什么会不一致

这种问题最麻烦的地方不是报错本身，而是“为什么测试环境不报、生产环境报”。排查下来最常见的原因有三个：

开发环境是 5.6 或更早版本，生产环境是 5.7+，本地没复现条件。
开发、测试、生产虽然都是 5.7+，但维护方为了兼容老代码，曾经把测试环境的 sql_mode 里的 ONLY_FULL_GROUP_BY 去掉了，生产环境却还保留着。
使用云数据库时，不同参数组模板的默认值不一致。你手工建实例和通过备份恢复的实例，参数组可能不是同一个。

一旦出现这三类情况中的任意一种，GROUP BY 相关 SQL 的行为就会分叉：一边能查到数据，另一边直接 1055。而且这种分叉是最隐蔽的，因为你在开发环境测试一百遍都测不出问题，代码评审也看不出毛病。

1.3 这类事故给团队的两个教训

第一个教训：新项目启动时，必须在初始化脚本里把 sql_mode 固定下来，而不是依赖实例的默认参数。第二个教训：团队应该尽早统一 MySQL 大版本，并且把 sql_mode 的差异写进变更检查清单。MySQL 升级从来不只是 apt upgrade 或二进制替换那么简单，“版本变了，默认行为可能也变了”才是真正需要花时间评估的部分。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. sql_mode 到底是什么？ONLY_FULL_GROUP_BY 在“管”哪些行为

2.1 sql_mode 是一组行为开关，不是单个配置项

sql_mode 是 MySQL 提供的一组会话级/全局级变量，用来控制服务器对 SQL 语法和合法性检查的宽容程度。你可以把它理解成一套“执法尺度”集合：开了严格模式，非法日期、除零、字符串截断这些操作会直接报错；不开严格模式，很多问题只会产生告警甚至被静默修正。

常见的几个开关各有分工：

sql_mode 项	作用
STRICT_TRANS_TABLES	对事务表开启严格模式，写入非法值时报错而非告警
ONLY_FULL_GROUP_BY	约束 GROUP BY 查询中 SELECT/HAVING/ORDER BY 对非聚合列的引用
NO_ZERO_DATE	禁止插入/更新 '0000-00-00' 日期
NO_ZERO_IN_DATE	禁止插入/更新含 0 部分的日期，如 '2024-00-19'
ERROR_FOR_DIVISION_BY_ZERO	除零操作直接报错
NO_ENGINE_SUBSTITUTION	建表指定引擎不可用时直接报错而非自动替换

从 5.7.5 开始，官方把 ONLY_FULL_GROUP_BY 加进了默认组合，8.0 继续沿用，说明 MySQL 官方已经决心让自己更靠近标准 SQL 的行为。

2.2 ONLY_FULL_GROUP_BY 的具体限制范围

sql_mode 中如果包含 ONLY_FULL_GROUP_BY，MySQL 会对下面三类位置做同样的检查：

SELECT 列表中的非聚合列。
HAVING 条件中引用的非聚合列。
ORDER BY 排序中引用的非聚合列。

凡是出现在这些位置的列，要么必须出现在 GROUP BY 子句中，要么必须被聚合函数包裹，否则就报 1055。

注意这里说的“位置”不只指分组查询中真正参与分组的列，也包括分组结果里被查询的字段本身。很多开发者的第一反应是：“user_name 和 user_id 一一对应啊，放上去没问题吧？”你心里认为没问题，MySQL 很难判断是不是一一对应，而且如果业务上真没有唯一约束，这个假设本来就是靠不住的。

2.3 为什么 MySQL 曾经允许这种“不严谨”的 SQL

这涉及 MySQL 对 GROUP BY 的历史实现。在标准 SQL 中，GROUP BY 的结果集是一个分组后的集合，每一组会压缩成一行。如果 SELECT 列表里写了一个不属于分组键的普通列，那这一行到底该取哪一行数据，标准 SQL 根本不承认这种写法。

MySQL 早期选择了一条更宽松的路线：分组后如果遇到非聚合列，就从组内物理第一条或接口层选中的一行中取值。对很多“先取一个再说”的业务来说，这种写法省事，但也制造了一大批“看起来能跑、结果全凭运气”的 SQL。等到版本升级后，同一个查询在不同数据分布下返回的行可能完全不同，这也是一些“奇怪 bug”的真正源头。

3. 合规判定规则：一组“能过”和“不能过”的真实对比

3.1 三条最核心的判定线

直接看例子更容易理解，我用玩家订单表来说明，表结构如下：

sql复制CREATE TABLE player_order (
    id INT PRIMARY KEY AUTO_INCREMENT,
    player_id INT NOT NULL,
    player_name VARCHAR(50),
    game_id INT NOT NULL,
    amount DECIMAL(10,2) NOT NULL,
    created_at DATETIME
);

判断一条 SQL 是否违反 ONLY_FULL_GROUP_BY，我习惯按顺序问三个问题：

第一，GROUP BY 后面写了哪些列？第二，SELECT、HAVING、ORDER BY 里出现了一个普通列，它是否在 GROUP BY 列表里？第三，如果不在，它是不是被 COUNT()、SUM()、MAX()、MIN() 这类聚合函数包住了？

如果第三个问题也是否，那这条 SQL 就处在违规边缘。下面这几条都有问题：

sql复制-- 反例1：SELECT 带了非聚合列 player_name
SELECT player_id, player_name, SUM(amount)
FROM player_order
GROUP BY player_id;

-- 反例2：HAVING 里用非聚合列做筛选
SELECT player_id, SUM(amount)
FROM player_order
GROUP BY player_id
HAVING player_name = 'zhangsan';

-- 反例3：ORDER BY 里排序了非聚合列
SELECT player_id, SUM(amount)
FROM player_order
GROUP BY player_id
ORDER BY player_name;

3.2 例外一：函数依赖（Functional Dependency）

规则不是死的。MySQL 5.7.5 之后支持“函数依赖”检测，如果 GROUP BY 的列是主键，或者是带 NOT NULL 的唯一索引，那同一张表里的其他列就被认为是“函数依赖于”这个分组键。

sql复制-- 合法：id 是主键
SELECT id, player_name, MAX(amount)
FROM player_order
GROUP BY id;

为什么这条合法？因为 GROUP BY id 意味着每个分组只包含一行（同一主键不可能出现两组），那 player_name 取哪个值是唯一确定的，不会产生歧义。这种设计给了开发者一些绕行空间，也避免了很多“为了不报错而硬包一层聚合”的尴尬场景。

但函数依赖检测也有它的局限。使用 JOIN 或子查询时，MySQL 不一定能推导出“外层查询的分组列在底层是主键”。比如把上面的查询包一层子查询再分组，MySQL 无法确认 id 仍然具备唯一性，就可能照样报错。

3.3 例外二：常量、字面量和明确确定值的表达式

SELECT 'hello', COUNT(*) FROM t GROUP BY id 不会报错，因为 'hello' 是一个常量，每个分组里取它都是同一个值，没有歧义。另一类是确定性表达式，例如 SELECT id+0, COUNT(*) FROM t GROUP BY id，id+0 的计算结果由分组键决定，因此合法。

但如果你写 SELECT amount * 1.2 FROM t GROUP BY id，amount 是普通列而不是分组键，即使乘了个系数也不能改变 MySQL 对“非聚合列”的识别，仍然报错。

3.4 一张能直接对照的合规速查表

SQL 写法	是否合规	原因
`SELECT player_id, SUM(amount) FROM t GROUP BY player_id`	合规	只查分组键和聚合结果
`SELECT player_name, COUNT(*) FROM t GROUP BY player_name`	合规	字段出现在 GROUP BY
`SELECT player_id, player_name, SUM(amount) FROM t GROUP BY player_id`	违规（无函数依赖时）	player_name 既不在分组键也不是聚合
`SELECT id, player_name, MAX(amount) FROM t GROUP BY id`	合规	id 为主键，函数依赖成立
`SELECT player_id, ANY_VALUE(player_name), SUM(amount) FROM t GROUP BY player_id`	合规	ANY_VALUE 显式忽略取值歧义
`SELECT COUNT(DISTINCT player_name), amount FROM t GROUP BY player_id`	违规	amount 未聚合且不在分组键中

这张表可以直接作为代码评审时的快速参考。

4. 不同报错场景的完整复盘：问题往往不只是 SELECT 列表

4.1 场景一：同一个分组键下有多行不同取值，你期待哪一行？

最经典的是订单表按用户分组后取用户名。真实业务里，用户名可能修改过、平台可能存在多个子账号，user_id 并不总对应唯一 user_name。在 ONLY_FULL_GROUP_BY 关闭时，MySQL 会随手取一行；开启后直接拒绝。此时不要抱怨“以前都能跑”，而应该思考：如果真的存在一个 user_id 对应多个 user_name，你想返回哪一个？这个思考结果决定你应该用 MIN(user_name)、ANY_VALUE、子查询还是重新设计查询。

4.2 场景二：GROUP BY 主键后，为什么在 JOIN 里还是报错？

前面说过，函数依赖让 GROUP BY 主键 的查询可以顺手查同表字段。但一旦表参与了 JOIN，MySQL 对函数依赖的推导会变保守，因为它要保证外层查询的结果不会因为连接关系而产生歧义。

假设：

sql复制SELECT
    o.id,
    o.player_name,
    SUM(o.amount)
FROM player_order o
JOIN player_info p ON p.player_id = o.player_id
GROUP BY o.id;

这个查询在某些数据下可以通过，某些数据下可能报错，尤其是 JOIN 导致一行 o.id 匹配到多行 p 时，player_name 的取值不再唯一。遇到这种情况，别纠结，直接显式让字段出现在聚合函数里，或者把 JOIN 后的结果先做子查询再分组。

4.3 场景三：HAVING 和 WHERE 的边界被混淆

对很多新手来说，HAVING 和 WHERE 的分工本身就是个模糊地带。WHERE 是在分组前对原始行做过滤，所以里面引用普通列没有任何问题；HAVING 是在分组后对分组结果做过滤，所以在 ONLY_FULL_GROUP_BY 下，HAVING 里直接写普通列就属于违规操作。

正确做法是：凡是“筛选分组前数据”的条件一律放 WHERE；只有比如 HAVING COUNT(*) > 1 这种基于分组聚合结果的过滤才放 HAVING。如果你确实想表达“过滤掉用户名等于 zhangsan 的分组”，把条件挪到 WHERE 后用普通查询即可。

4.4 场景四：视图和存储过程里的“定时炸弹”

视图在创建时不一定会对 GROUP BY 查询做完整校验，但查询视图时会沿用当前会话的 sql_mode。你在一台 5.6 实例上建了一个“宽松型”视图，迁移到 5.7 后对视图做 SELECT *，报错可能出现在视图内部的普通列引用上。存储过程同理，可能在 CREATE PROCEDURE 阶段不暴露问题，第一次 CALL 才翻车。

这里我的经验是：在涉及视图、存储过程的迁移项目里，先用 SHOW CREATE VIEW 和 SHOW CREATE PROCEDURE 把所有对象导出来，再用目标版本的 sql_mode 从头执行一遍。这一步能堵住大多数隐藏雷。

4.5 三个常见的错误认知

先纠正三个说法：

“我在 SELECT 里把 GROUP BY 字段放第一位就行了” —— 错，那不叫合规。
“加上 DISTINCT 就能绕过” —— 错，DISTINCT 影响的是结果去重逻辑，不会改变非聚合列的判定。
“我试过 GROUP_CONCAT，它算聚合函数，其他字段就能随便带” —— 错，GROUP_CONCAT 只是其中一个字段被聚合了，其他普通列仍然要接受判定。

这些认知的背后都是没有理解“分组后一行数据里非聚合列的值并未确定”这个核心矛盾。理解这一点，做 SQL 评审时就不会只看表面语法了。

5. 不伤筋动骨的解法：SQL 改写三板斧与各自代价

5.1 第一板斧：把字段加进 GROUP BY

把 user_name 也写进 GROUP BY 是最直接的合规方式：

sql复制SELECT user_id, user_name, MAX(order_amount)
FROM orders
GROUP BY user_id, user_name;

这时分组的粒度从“用户”变成“用户 + 用户名”。如果用户只有一个用户名，结果和之前想的一样；如果同一个用户存在多个用户名，每个用户名都会产生一组，最终得到的行数会多于“每个用户一行”的预期。

所以这种方案只适合“字段和主键天然绑定”的场景，不适合不确定字段。用它之前，先评估分组粒度变化是否影响业务。

5.2 第二板斧：使用 ANY_VALUE 明确表达意图

MySQL 5.7.5 起提供了 ANY_VALUE() 函数，可以包住非聚合列。它告诉 MySQL：“我知道这个字段在组内可能多值，取哪个都可以，出了歧义我自己承担。”

sql复制SELECT
    user_id,
    ANY_VALUE(user_name) AS user_name,
    MAX(order_amount) AS max_amount
FROM orders
GROUP BY user_id;

这个方案在“取哪个值都无所谓”时很好用。不过提醒一句：ANY_VALUE 不保证每次取同一行，如果你只是暂时不想报错，后面却拿这个字段做业务判断，那等于给自己埋雷。正式项目里我一般会在代码注释里写明“该字段非确定性，仅供展示，勿参与业务逻辑”。

5.3 第三板斧：用 MIN/MAX 聚合是“偷懒”，不是“治本”

有人喜欢把非聚合列改成 MIN(user_name) 或 MAX(user_name) 来绕过检查，这在语法上是合规的，但很容易产生一个隐蔽问题：你取到的用户名和查出来的 MAX(order_amount) 不是同一行。

“取金额最大那单的用户名”和“取用户名的最小字典序”，没有任何语义等价性。如果业务想表达的就是后者，那这么写没问题；如果业务实际上想知道“最大金额那单是谁下的”，正确的写法通常是子查询。

5.4 正确姿势：子查询先定位目标行，再 JOIN 回原表

“每个用户金额最大的那笔订单，以及它的完整订单信息”——这是 GROUP BY 场景下最常见的真实需求，靠 MAX(order_amount) 加上 user_name 根本无法实现，因为聚合后其他列的取值可能不属于同一条记录。

推荐做法：

sql复制SELECT o.*
FROM player_order o
JOIN (
    SELECT player_id, MAX(amount) AS max_amount
    FROM player_order
    GROUP BY player_id
) t ON t.player_id = o.player_id AND t.max_amount = o.amount;

这段 SQL 先把“每个用户的最高金额”算出来，再回到原表找到真正达到这个金额的那笔订单，此时查询的 o.* 每一列都来自真实行，完全不存在不确定值，也天然符合 ONLY_FULL_GROUP_BY 的要求。

5.5 更现代的做法：窗口函数解决“分组取前 N”

MySQL 8.0 支持窗口函数后，很多 GROUP BY 解决不了的问题可以换种思路。比如想取每个用户最近一单的信息：

sql复制SELECT player_id, player_name, order_amount, created_at
FROM (
    SELECT
        player_id,
        player_name,
        order_amount,
        created_at,
        ROW_NUMBER() OVER(PARTITION BY player_id ORDER BY created_at DESC) AS rn
    FROM player_order
) t
WHERE rn = 1;

窗口函数本质上没有把行“压扁”，所以不用纠结哪列值不确定，每组都能保留整行数据。这个方案在 MySQL 8.0 环境里越来越值得优先考虑。

5.6 不同业务语义下的 SQL 方案选择

业务诉求	推荐方案	不推荐的理由
只要每个分组某个字段的聚合值	直接聚合	—
分组后展示一个“不关心取哪个”的附属字段	ANY_VALUE	MIN/MAX 有误导性
每组的取值必须来自同一条具体记录	子查询 JOIN / 窗口函数	加 GROUP BY 会产生多余分组
结果容忍一行分成多组展示	把字段加进 GROUP BY	行数可能膨胀
取每个分组里排序第一的完整行	窗口函数	子查询写法复杂、性能不一定好

方案没有绝对优劣，关键是先想清楚“业务到底要什么”。这也是我在代码评审里说得最多的一句话。

6. 什么时候能改 sql_mode？修改方法和风险评估

6.1 查看当前设置

动手之前先确认状态：

sql复制-- 查看当前会话
SELECT @@SESSION.sql_mode;

-- 查看全局
SELECT @@GLOBAL.sql_mode;

默认情况下，5.7.5+ 和 8.0 的控制台输出里都包含 ONLY_FULL_GROUP_BY。如果当前会话和全局不一致，你验证 SQL 时可能做了“假测试”，所以排查时一定要确认这两层都在你预期的值上。

6.2 临时修改：会话级和全局级

如果你只是想测试一条 SQL 在宽松模式下的表现，可以移除当前会话的模式开关：

sql复制SET SESSION sql_mode = (SELECT REPLACE(@@SESSION.sql_mode, 'ONLY_FULL_GROUP_BY', ''));

做完测试后重启会话即恢复。注意这个操作只影响当前连接，不影响其他连接，非常安全。

如果你确定要全局改，可以这样：

sql复制SET GLOBAL sql_mode = (SELECT REPLACE(@@GLOBAL.sql_mode, 'ONLY_FULL_GROUP_BY', ''));

但 SET GLOBAL 只对之后新建的连接生效，已经存在的连接不会跟着变，这在长连接池场景下很容易造成“参数改了，线上还在报错”的假象。执行完全局修改以后，建议同时把连接池里的旧连接重启或让应用发布一次。

6.3 持久化修改：MySQL 8.0 的 SET PERSIST

MySQL 8.0 引入了 SET PERSIST，可以把配置写进数据目录下的 mysqld-auto.cnf，重启也不会丢：

sql复制SET PERSIST sql_mode = (SELECT REPLACE(@@sql_mode, 'ONLY_FULL_GROUP_BY', ''));

如果你用的是 5.7 或更早版本，需要改 my.cnf：

ini复制[mysqld]
sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

改完重启 MySQL 服务才生效。云数据库实例一般不支持直接改配置文件，需要走控制台的参数组管理页面，修改后通常会自动重启实例。这类操作在业务高峰期要谨慎。

6.4 要不要改？我的建议是先量化评估

“删掉 ONLY_FULL_GROUP_BY 不就行了吗？”这是最常听到的回应。但我不建议你无脑移除，原因有三。

第一，它不是报错的根源，只是把问题透明化。真正的问题是业务 SQL 本身依赖了“不确定行为”，即使当前数据看起来正常，以后数据分布一变化，结果可能悄悄改变。第二，和官方默认行为对着干，会让团队内部出现“开发环境一个样、生产环境一个样”的问题。第三，未来升级大版本、使用托管数据库时，默认值大概率会重新带上这个开关，到时候你还是要还这波技术债。

如果团队确实有大量历史 SQL 需要平滑过渡，我建议按下面四步走：

第一步，先收集慢查询日志、错误日志里所有 1055 报错，确认影响范围。
第二步，让开发同学按“能改 SQL 就改 SQL”的原则处理，只有确实改不了的老旧系统才允许在数据库层面放开。
第三步，正式放开前，把 SET GLOBAL sql_mode 做成变更工单，留下回退方案。
第四步，在监控里保留一条定时检查，定期扫描新上线代码中是否又引入了宽松模式的 SQL，避免问题反弹。

我自己踩过多次之后得出的经验是：ONLY_FULL_GROUP_BY 不该是敌人，它更像是帮你揪出历史 SQL 中“下一步可能给你带来线上事故”的那些隐患。改 SQL 是最优解，改配置是兜底方案。

7. 从定位到面试：ONLY_FULL_GROUP_BY 相关的高频问题清单

7.1 报错后的快速定位手段

如果你的系统里已经积压了很多 SQL，不知道哪些触发了 1055，可以分两步排查。

先确认当前是否有报错产生，用 performance_schema 里的 events_statements_current 或打开 general_log 观察业务高峰期的报错语句。general_log 对生产环境有性能影响，建议开启时间不要超过几分钟，或用 grep 过滤包含 ERROR 1055 和 only_full_group_by 的日志行。

拿到具体 SQL 后，重点检查三点：SELECT 列表里有没有非聚合列、HAVING 里有没有非聚合列、ORDER BY 里有没有非聚合列。对照本文第三部分的速查表就能快速定性。

7.2 5.7 和 8.0 里 GROUP BY 的另一处行为差异

8.0 在移除 ONLY_FULL_GROUP_BY 之外，还移除了 GROUP BY 的隐式排序。5.7 及以前，SELECT * FROM t GROUP BY col 的结果集默认按 col 排序；8.0 里没有这个保证，要排序必须显式写 ORDER BY。

这个变化经常和 ONLY_FULL_GROUP_BY 一起在升级文档里出现，但它俩是两码事。面试时如果能把这两个差异都讲清楚，通常会被认为真的有升级实操经验，而不仅仅是背了文档。

7.3 关于“为什么不推荐关闭”的面试表达

面试里如果被问到“线上遇到大量 1055，能不能把 ONLY_FULL_GROUP_BY 关了”，不要单纯回答“能”或“不能”。比较好的表达结构是：先说它的作用是保证分组查询结果确定性；再说历史版本为什么没有默认开启；然后说关闭方案的代价和风险；最后给出推荐的解决路径（先找 SQL，再改写，最后才考虑改配置）。

这套表达背后折射的是一个人面对“配置项能解决眼前问题”时的判断力。MySQL 的参数非常多，有些配置项改了马上见效，但后面会以更隐蔽的方式反噬你，sql_mode 就是这类参数的典型代表。

7.4 跟其他数据库做对比，能加深理解

PostgreSQL 从很早开始就严格执行标准 SQL 的 GROUP BY 规则，聚合查询里出现非分组键、非聚合列的情况直接被拒。SQL Server 也类似。相比之下，MySQL 的宽松模式曾经是异类，后来才逐步收紧。

这也是为什么很多从 Oracle、SQL Server 迁到 MySQL 5.7 的数据库工程师会觉得 MySQL 更“好说话”，而从 MySQL 5.6 迁到 5.7 的人会觉得天塌了。理解了这一个背景，你就知道当前默认开启 ONLY_FULL_GROUP_BY 其实是 MySQL 向标准靠拢的结果，而不是某个版本拍脑袋加的配置。

我自己现在写 SQL 的默认习惯是：凡是用到 GROUP BY，不管环境开没开 ONLY_FULL_GROUP_BY，都假设它是开启的。分组键之外的列不是放进聚合函数，就是通过子查询、窗口函数精确定位到某一行。这个习惯帮我避开了不止一次莫名其妙的数据结果偏差。如果你之前写 SQL 一直依赖宽松模式，建议从今天开始也按这个标准要求自己，等哪天环境收紧的时候，你会感谢当初这点“多余的自觉”。