解决 SQL 错误 [1055]：深入理解 only_full_group_by 模式下的查询规范
在日常的 SQL 开发中，你是否遇到过这样的报错：SQL 错误 [1055] [42000]: Expression #N of SELECT list is not in GROUP BY clause and contains nonaggregated column...？尤其是在 MySQL 5.7 及以上版本中，这个错误更为常见。本文将详细解析这个错误的产生原因，并提供具体的解决方案，帮助你快速定位并解决问题。
一、错误现象与核心原因
当执行 SQL 查询时出现[1055]错误，核心原因只有一个：你的查询违反了sql_mode=only_full_group_by的约束规则。这是 MySQL 中一个重要的 SQL 模式，也是导致该错误的直接 “元凶”。
什么是 only_full_group_by？
only_full_group_by是 MySQL 的sql_mode中的一项配置，其核心作用是规范 GROUP BY 查询的语法逻辑。当启用该模式时，MySQL 强制要求：SELECT 语句中出现的所有非聚合列（未使用 SUM、COUNT、MAX 等聚合函数的列），必须全部包含在 GROUP BY 子句中。
简单来说，GROUP BY 的本质是将数据按指定列分组，分组后每组只会保留一条 “代表性” 数据。如果 SELECT 中存在未在 GROUP BY 中声明的非聚合列，这些列可能在同一分组中存在多个不同值，MySQL 无法确定应该返回哪个值，因此会直接报错。
二、错误实例分析
为了更直观地理解问题，我们通过一个具体案例来拆解错误产生的过程。
场景假设
现有一张订单表orders，结构如下：
字段名 | 类型 | 说明 |
order_id | int | 订单 ID（主键） |
user_id | int | 用户 ID |
user_name | varchar | 用户名 |
order_amount | decimal | 订单金额 |
create_time | datetime | 下单时间 |
错误查询示例
假设我们需要查询每个用户的总订单金额，编写了如下 SQL：
SELECT user_id, user_name, SUM(order_amount) AS total_amount,create_time -- 问题列：未在GROUP BY中，也未聚合FROM orders GROUP BY user_id; -- 仅按user_id分组报错原因
上述查询中，create_time是第 4 个字段（对应报错中的 “Expression #4”），它既没有出现在 GROUP BY 子句中，也没有使用聚合函数（如 MAX (create_time)）。在only_full_group_by模式下，MySQL 无法确定每个用户分组应返回哪个create_time（一个用户可能有多个订单，对应多个下单时间），因此直接抛出[1055]错误。
三、解决方案
针对[1055]错误，我们有三种常见的解决思路，每种思路适用于不同场景，需根据实际需求选择。
方案 1：将非聚合列添加到 GROUP BY 子句
如果 SELECT 中的非聚合列与 GROUP BY 列存在功能依赖关系（即分组列能唯一决定非聚合列的值，如user_id唯一对应user_name），可以将非聚合列直接添加到 GROUP BY 中。
修改后的查询：
SELECT user_id, user_name, SUM(order_amount) AS total_amount,create_timeFROM orders GROUP BY user_id, user_name, create_time; -- 补充非聚合列到GROUP BY方案 2：对非聚合列使用聚合函数
如果非聚合列不需要精确值，只需获取分组中的 “代表性” 数据（如最新时间、最大 ID 等），可以通过聚合函数处理。
修改后的查询：
SELECT user_id, user_name, SUM(order_amount) AS total_amount,MAX(create_time) AS last_order_time -- 用MAX聚合获取最新下单时间FROM orders GROUP BY user_id, user_name; -- user_name与user_id功能依赖，需一起分组方案 3：临时关闭 only_full_group_by 模式（不推荐）
如果暂时无法调整查询逻辑，可通过修改sql_mode关闭only_full_group_by。但这是临时解决方案，可能导致数据歧义，不建议在生产环境使用。
步骤 1：查看当前 sql_mode
SELECT @@sql_mode;执行后会显示包含ONLY_FULL_GROUP_BY的模式列表。
步骤 2：临时关闭（重启 MySQL 后失效）
SET sql_mode = (SELECT REPLACE(@@sql_mode, 'ONLY_FULL_GROUP_BY', ''));步骤 3：永久关闭（需修改配置文件）
- 找到 MySQL 配置文件（Linux 通常是/etc/my.cnf，Windows 是my.ini）；
- 在[mysqld]下添加：
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION- 重启 MySQL 服务。
四、最佳实践
- 遵循 only_full_group_by 规范：这是最推荐的做法，通过调整查询逻辑（补充 GROUP BY 列或使用聚合函数）确保 SQL 符合模式要求，避免数据返回歧义。
- 理解功能依赖：如果非聚合列与 GROUP BY 列存在严格的一一对应关系（如user_id唯一决定user_name），将非聚合列添加到 GROUP BY 是安全且高效的。
- 避免随意修改 sql_mode：only_full_group_by是 MySQL 的安全机制，关闭后可能导致查询结果不可控，尤其在多人协作的项目中应谨慎操作。
总结
SQL 错误 [1055]的本质是only_full_group_by模式对 GROUP BY 查询的语法约束。解决问题的核心在于确保 SELECT 中的非聚合列全部包含在 GROUP BY 中，或通过聚合函数处理。理解这一机制不仅能解决报错，更能帮助我们写出更规范、更可靠的 SQL 查询。