破案实录：当 DISTINCT 遇上 ORDER BY，我是如何用一行SQL拯救本地环境的

原创于 2025-09-24 16:54:11 发布 · 1.2k 阅读

26 ·

CC 4.0 BY-SA版权

文章标签：

#sql #数据库

Spring Data JPA 同时被 2 个专栏收录

207 篇文章

订阅专栏

MySQL高级篇

79 篇文章

订阅专栏

🚀 破案实录：当 `DISTINCT` 遇上 `ORDER BY`，我是如何用一行SQL拯救本地环境的

嘿，各位在代码世界里探案的伙伴们！👋

我们都曾陷入过那个令人抓狂的“我本地有问题，但线上好好的”的神秘怪圈。你盯着代码，代码也盯着你，一切看起来都完美无瑕，但错误就像幽灵一样，只在你自己的电脑上出现。

今天，我想分享一次我亲身经历的破案过程。一个健壮的导出功能，在生产环境表现优异，却在我的本地开发环境，被一条冷冰冰的 SQL (Structured Query Language, 结构化查询语言) 错误挡住了去路：

[HY000][3065] Expression #2 of ORDER BY clause is not in SELECT list ... this is incompatible with DISTINCT

[2025-09-24 16:39:54] [HY000][3065] Expression #2 of ORDER BY clause is not in SELECT list, 
references column 'productqualification.p.created_date' which is not in SELECT list; 
this is incompatible with DISTINCT

最终，我并没有修改任何一行 Java 代码，而是通过一行神奇的 SQL 命令，让本地环境“乖乖听话”，成功解决了问题。让我们一起回顾这次精彩的探案之旅！

案发现场：一条“挑剔”的 SQL

故事的起因是，我的 Spring Boot 应用在执行一个产品导出功能时，Hibernate 生成了如下一条 SQL 语句：

SELECT DISTINCT 
    p.code, p.name, b.english_name as brand, ... -- 省略了大量字段
FROM 
    product p 
    INNER JOIN brand b ON p.brand_id = b.id
    -- ... 其他 JOIN ...
WHERE 
    -- ... 过滤条件 ...
ORDER BY 
    p.ranks DESC, p.created_date DESC; -- 👈 问题的导火索

问题分析：

SELECT DISTINCT: 查询要求返回唯一的记录。
ORDER BY p.ranks DESC, p.created_date DESC: 排序要求先按 ranks 降序，再按 created_date 降序。
矛盾点: SELECT 的字段列表里包含了 p.ranks，但没有包含 p.created_date！

当这条 SQL 发送到我本地的 MySQL 数据库时，它毫不留情地抛出了 HY000 错误。然而，同样的代码、同样的 SQL 逻辑，在线上环境却跑得一帆风顺。

探案开始：寻找“双面”数据库的真面目

“线上可以，本地不行”，这几乎总是环境差异的代名词。既然代码和 SQL 逻辑都一样，那么唯一的变量就是数据库本身的行为。

我决定调查一下线上和本地数据库的“性格”——它们的 sql_mode 配置。sql_mode 决定了 MySQL 对 SQL 语法的校验有多严格。

我分别在两个环境的数据库客户端里执行了查询：

SELECT @@SESSION.sql_mode;

结果令我大吃一惊！

线上数据库 😇 (宽容的老好人):
```
STRICT_TRANS_TABLES
```
这是一个相对基础的严格模式，它并不关心 DISTINCT 和 ORDER BY 的这点“小事”。
本地数据库 🧐 (严谨的语法教授):
```
ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,...
```
这是一个非常全面的严格模式集合。其中，正是 ONLY_FULL_GROUP_BY 所在的这个严格模式组合，强制执行了 SQL 的一条标准规范：

当使用 SELECT DISTINCT 时，ORDER BY 子句中的所有列都必须出现在 SELECT 的列清单中。

真相大白！ 我的本地数据库因为配置了更严格的 sql_mode，所以拒绝执行那条它认为“不规范”的 SQL。而线上数据库配置更宽松，所以放行了。

解决方案：让本地数据库“入乡随俗”

既然找到了问题的根源，我面临两个选择：

修改 Java 代码: 让 SELECT 子句包含 p.created_date。这是最根本、最健壮的解决方案。
修改本地环境: 让我的本地数据库的行为和线上保持一致，以便更真实地模拟生产环境。

在某些情况下，比如当你不想为了一个临时的本地调试而去改动稳定的代码时，第二种方案就显得非常实用。

我选择了在我的数据库客户端会话中，临时改变 sql_mode。

神奇的一行 SQL 命令：

SET SESSION sql_mode = 'STRICT_TRANS_TABLES';

这行代码做了什么？

SET SESSION: 这个命令告诉数据库，我接下来的设置只对当前这个连接会话有效。它不会改变数据库的全局默认配置，也不会影响其他人的连接。
sql_mode = 'STRICT_TRANS_TABLES': 我将当前会话的 sql_mode，强制设置成了和线上环境一模一样的宽松模式。

执行完这条命令后，我再次运行之前那条报错的 SELECT DISTINCT ... ORDER BY SQL，奇迹发生了——它成功执行，并返回了正确的数据！ 🎉

结论与反思

这次排查经历，让我深刻体会到：

环境一致性是王道：保持开发、测试、生产环境（特别是数据库 sql_mode 这类底层配置）的一致性，可以消灭大量“只在我电脑上有问题”的诡异 Bug。
SET SESSION 是调试利器：当你需要临时模拟不同数据库行为时，SET SESSION 命令是一个无价之宝。它能让你在不影响全局配置的情况下，安全地进行各种测试。
理解错误信息：仔细阅读数据库的报错信息，它往往直接指明了问题的根源。这次的 incompatible with DISTINCT 就是最关键的线索。
知其所以然：不仅要解决问题，更要理解背后的原因。了解 sql_mode 中不同模式的含义，能让你在未来写出更健壮、更具兼容性的 SQL。

虽然最终的解决方案只是一行 SQL，但找到它的过程却是一次宝贵的学习经历。希望我的分享，也能在你未来的“探案”之路上，提供一些有用的线索。

Happy Coding! 💻✨

总结与图表分析 📊

📝 问题排查与解决总结表

步骤 (Step)	动作 (Action)	发现 (Finding)	结论 (Conclusion)
1️⃣ 现象复现	本地执行导出	SQL 报错 `incompatible with DISTINCT`	本地环境存在问题
2️⃣ 对比验证	线上执行相同操作	导出成功，无报错	本地与线上环境存在差异
3️⃣ 定位差异	分别查询本地和线上的 `sql_mode`	本地 `sql_mode` 更严格 (含 `ONLY_FULL_GROUP_BY` 组合)	`sql_mode` 不一致是根本原因
4️⃣ 临时解决	本地会话执行 `SET SESSION sql_mode`	SQL 不再报错，导出成功	临时修改会话 `sql_mode` 有效
5️⃣ 长远方案	修复 Java 代码或同步环境配置	N/A	确保代码健壮性或环境一致性

🗺️ 流程图：问题诊断决策流程

🔄 时序图：`sql_mode` 如何影响数据库行为

🚦 状态图：数据库会话的不同 `sql_mode` 状态

🏛️ 类图：概念关系

🔗 Mermaid 流程图示例：

🧠 思维导图 (Markdown Format)

Bug排查实录：解决本地SQL报错
- 🎯 现象
  - 问题: 本地导出时，数据库报错 Expression #2 of ORDER BY clause is not in SELECT list... incompatible with DISTINCT
  - 背景: 线上环境相同操作正常
- 🤔 探案过程
  - 1. 提出假设: 本地与线上环境存在差异
  - 2. 定位差异:
    - 动作: 分别查询本地和线上的 @@SESSION.sql_mode
    - 发现:
      - 线上: STRICT_TRANS_TABLES (相对宽松)
      - 本地: ONLY_FULL_GROUP_BY,... (非常严格)
  - 3. 分析原因:
    - 规则: MySQL 严格模式要求 SELECT DISTINCT 查询的 ORDER BY 列必须出现在 SELECT 列表中
    - 根源: 本地数据库的 sql_mode 配置比线上更严格，导致同一条 SQL 行为不一致
- 💡 解决方案
  - 方案一 (临时解决/环境模拟):
    - 命令: SET SESSION sql_mode = 'STRICT_TRANS_TABLES';
    - 作用: 将当前会话的 sql_mode 临时修改为与线上一致，使 SQL 不再报错
  - 方案二 (长远解决/代码健壮性):
    - 动作: 修改 Java 代码，确保 SELECT 子句包含 ORDER BY 用到的所有列
- 🌟 经验反思
  - 环境一致性: 保持开发、测试、生产环境的配置（尤其是 sql_mode）一致至关重要
  - SET SESSION: 是一个强大的本地调试工具
  - 理解SQL规范: 深入理解数据库的严格模式，编写更具兼容性的代码