MySQL utf8mb4 排序规则不一致时怎么处理连接报错

MySQL 报 utf8mb4 排序规则错误时，先不要把所有表都改成同一个名字。看错误码更快：1273 Unknown collation 多半是客户端、连接参数或导入脚本请求了服务端不认识的排序规则；1267 Illegal mix of collations 则通常发生在查询比较阶段，两个字符串来源的排序规则无法按当前表达式规则合并。前者先解决“能不能建立兼容的会话”，后者再解决“哪两个值在比较”。

先按错误码判断是连接不兼容还是表达式冲突

“utf8mb4 排序规则不一致”不是一个单一故障。MySQL 1273 的含义是 Unknown collation：请求中的排序规则在当前服务端不可用，常见于把新环境导出的建表语句直接交给较老服务端，或驱动连接参数固定了目标环境才有的排序规则。这个阶段还没有进入业务查询，改 WHERE 条件没有意义。

1267 的 Illegal mix of collations 则是另一条路径。服务端已经认识这些排序规则，但表达式里的列、字符串字面量或连接会话设置无法形成一致比较规则。例如两个表的同名业务编码分别使用 utf8mb4_general_ci 和 utf8mb4_unicode_ci，执行等值连接时就可能触发它。

还有一个容易误判的点：排序规则不一致不一定让 TCP 连接失败。很多“连接报错”其实是连接建立后，连接池初始化执行 SET NAMES ... COLLATE ...，或者迁移脚本第一条 SQL 失败。先记录错误码和触发 SQL，再进入下一步。

检查连接会话实际使用的字符集和排序规则

连接成功后，在同一个连接、同一个连接池初始化路径里执行下面的查询。不要只看服务器启动参数，因为客户端连接可以覆盖会话级变量。

-- 查看当前连接发送、转换和返回结果时使用的字符集
SHOW VARIABLES WHERE Variable_name IN (
  'character_set_client',
  'character_set_connection',
  'character_set_results',
  'collation_connection'
);

-- 确认服务端默认值，便于和连接池配置对照
SELECT @@character_set_server, @@collation_server,
       @@character_set_database, @@collation_database;

MySQL 文档把 SET NAMES 'utf8mb4' 解释为同时设置客户端发送、连接转换和结果返回的字符集，并把连接排序规则设为该字符集的默认值。需要指定排序规则时才写成 SET NAMES 'utf8mb4' COLLATE '...'。因此排查时要确认连接池每次重连、读库连接和迁移连接是否都走了同一套初始化配置。

如果返回 1273，先用服务端支持列表确认名称，不要凭经验替换：

-- 只查看当前服务端真正支持的 utf8mb4 排序规则
SHOW COLLATION WHERE Charset = 'utf8mb4';

-- 在确认目标规则存在后，再为当前会话选择它
SET NAMES 'utf8mb4' COLLATE 'utf8mb4_unicode_ci';

上面的 utf8mb4_unicode_ci 只是示例，生产环境应选择目标服务端和业务排序语义都支持的规则。不能把“连接能建立”当成“排序语义已经正确”。

从列定义定位真正发生冲突的字段

连接变量正常后，再看参与查询的列。数据库、表和列都可能拥有自己的默认值，最终列定义比“数据库看起来是 utf8mb4”更接近故障现场。

-- 找出业务连接中两张表的字符列及其排序规则
SELECT TABLE_NAME, COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME IN ('customer', 'customer_archive')
  AND DATA_TYPE IN ('char', 'varchar', 'text', 'tinytext', 'mediumtext', 'longtext')
ORDER BY TABLE_NAME, ORDINAL_POSITION;

如果冲突发生在 customer.code = customer_archive.code，先确认两边的字符集是否都是 utf8mb4，再比较排序规则。字符集不同是更早一层的兼容问题，不能只靠换排序规则解决。若只是表默认值不同但列已经显式指定，修改表默认值也不会改变已有列。

长期修复通常是把同一业务键的列统一为同一字符集和排序规则，并把变更写入迁移脚本。修改前要考虑索引长度、唯一性语义和锁表窗口，尤其是把不区分大小写的比较改成区分大小写时，原本相等的值可能不再相等。

表达式冲突用 COLLATE 做最小范围修复

如果只是跨库兼容、历史表暂时不能改，先在表达式上显式指定排序规则，范围比整表改造小：

-- 两列都是 utf8mb4 时，先把比较规则写在冲突表达式上
SELECT c.id
FROM customer AS c
JOIN customer_archive AS a
  ON c.code COLLATE utf8mb4_unicode_ci
   = a.code COLLATE utf8mb4_unicode_ci;

-- 字面量比较也明确指定字符集和排序规则
SELECT id
FROM customer
WHERE code = _utf8mb4'AbC' COLLATE utf8mb4_unicode_ci;

COLLATE 不是万能转换器：两边字符集不兼容时，先处理字符集；目标排序规则在服务端不存在时，表达式本身仍会报错。并且把 COLLATE 写在索引列上可能影响优化器使用索引，需用执行计划和真实数据验证，不能只看查询返回正确。

如果连接、列、查询都需要统一，建议把选择固化为三层：连接初始化使用已确认的 utf8mb4 规则；新表和新列显式写 CHARACTER SET、COLLATE；跨历史表的查询在迁移完成前保留局部 COLLATE，并为它建立清理计划。这样不会靠每个开发者记住某个默认值。

一份能落地的兼容性检查清单

上线前至少在目标版本服务端执行一次建表迁移和连接初始化；对读写连接、后台任务和命令行迁移分别检查。排序规则涉及比较、唯一索引和排序结果，修复完成后要补一条包含大小写、重音或特殊字符的回归数据，而不是只测试 ASCII。

常见问题

utf8mb4_general_ci 和 utf8mb4_unicode_ci 能直接混用吗？

同一字符集不代表比较规则相同。能否混用取决于表达式和上下文；如果出现 1267，先显式统一比较规则，长期再统一相关列。

只执行 SET NAMES utf8mb4 就能解决所有问题吗？

不能。它主要解决连接会话的字符集设置，不能让服务端支持一个不存在的排序规则，也不会自动修改已有列的排序规则。

为什么数据库默认排序规则改了，旧列还是原来的？

数据库默认值主要影响后续创建对象的继承；显式列定义仍保持自身设置。应查询 INFORMATION_SCHEMA.COLUMNS，再决定是否迁移列。

参考：MySQL 8.4 Connection Character Sets and Collations、MySQL 8.4 Server Error Reference、MySQL 8.4 Collation Issues。