AWS RDS MySQL 5.6升级至5.7后查询结果差异原因咨询

这个问题我之前帮不少人排查过，在RDS上从MySQL 5.6升级到5.7时，默认配置的差异确实很容易导致这类查询结果不一致的情况。结合你说的5.6返回1条、5.7返回预期2条的场景，最可能的原因集中在这几个默认参数的变化上：

1. SQL模式（sql_mode）的默认值变更 #

这是最常见的诱因：

• RDS MySQL 5.6默认用的是宽松模式，sql_mode是空值，对SQL语法和执行的约束非常少；
• 而RDS MySQL 5.7默认开启了一堆严格模式参数，其中**ONLY_FULL_GROUP_BY**是最可能影响你查询结果的。

如果你的查询带了GROUP BY子句，在5.6的宽松模式下，哪怕SELECT里的非聚合列没出现在GROUP BY里，MySQL也不会报错，而是随便从每个分组里挑一行返回——这就可能把本来该分成两组的结果合并成一行（也就是你看到的1条结果）。但5.7开启ONLY_FULL_GROUP_BY后，会严格遵循SQL标准执行分组，每个分组都会被正确返回，自然就得到了你预期的2条结果。

2. 派生表合并优化（optimizer_switch的derived_merge） #

• RDS MySQL 5.6默认是关闭derived_merge的，也就是optimizer_switch里这个参数值是off；
• 到了5.7，这个优化默认是开启的（on状态）。

要是你的查询用到了派生表（比如FROM (SELECT ...) AS t这种写法），5.6会先单独跑派生表的查询，再和主查询关联；但5.7会把派生表的逻辑直接合并到主查询里，生成更高效的执行计划。这种合并可能会改变条件的执行顺序，导致5.6里被过滤掉的行，在5.7中被正确匹配到，结果行数自然就多了。

3. 默认字符集与排序规则的变化 #

• RDS MySQL 5.6的默认字符集一般是latin1，排序规则是latin1_swedish_ci；
• 5.7的默认字符集改成了utf8mb4，排序规则对应是utf8mb4_general_ci（部分区域可能是更严格的utf8mb4_unicode_ci）。

如果你的查询涉及字符串比较（比如WHERE col = 'xxx'），不同的排序规则会改变字符的匹配逻辑：有些字符在latin1的规则下会被判定为相同，但在utf8mb4下是不同的，反过来也一样。这直接就会导致匹配的行数不一样——5.6只匹配到1条，5.7却能匹配到符合预期的2条。

怎么验证具体是哪个原因？ #

你可以在两个RDS实例里分别跑这些SQL，对比参数取值就能确认：

-- 查看当前sql_mode
SELECT @@sql_mode;

-- 查看derived_merge的状态
SELECT @@optimizer_switch;

-- 查看数据库默认字符集和排序规则
SELECT @@character_set_database, @@collation_database;

内容的提问来源于stack exchange，提问作者KevinD