跨库JOIN失败的问题，排查起来其实并不复杂。核心原因并非库名不同，而是两个字段的COLLATION_NAME不兼容。MySQL在执行等值比较（=或JOIN ON）时，要求两侧字符串表达式的排序规则必须可比——即使字符集同为utf8mb4，utf8mb4_unicode_ci与utf8mb4_0900_as_cs也无法直接比较。这是很多开发者容易忽视的细节。

如何准确查询跨库字段的COLLATION

因此，第一步是直接查询字段定义，不要依赖数据库级别的默认值。使用INFORMATION_SCHEMA获取COLLATION_NAME的实际值：

• SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'db1' AND TABLE_NAME = 't1' AND COLUMN_NAME = 'code';
• SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'db2' AND TABLE_NAME = 't2' AND COLUMN_NAME = 'code';

请注意一个关键点：两个数据库可以使用相同的字符集，但只要COLLATION_NAME不同，就可能触发Illegal mix of collations错误。严格来说，这正是问题的根源。

检查连接层是否影响了字面量的排序规则

有时表结构看起来完全一致，但问题却出现在连接层。如果客户端连接的@@character_set_client设置为latin1或utf8（而非utf8mb4），SQL中的字符串字面量（如'abc'、参数占位符）会被MySQL按照错误规则解析，导致JOIN条件从一开始就出现偏差。

执行以下SQL语句查看实际连接状态：

SELECT @@character_set_client, @@collation_connection;

常见的错误配置包括：

• JDBC连接串中漏掉了&collationConnection=utf8mb4_0900_as_cs，仅写了useUnicode=true&characterEncoding=utf8mb4
• Python的pymysql库传递了charset='utf8'（而非预期的utf8mb4）
• 应用层通过SET NAMES utf8mb4设置了字符集，但未指定COLLATE，导致@@collation_connection仍为服务端默认值（例如utf8mb4_general_ci）

这些环节中任何一个未对齐，都可能导致跨库JOIN失败。

临时解决方案：在JOIN条件中显式指定排序规则

在生产环境中，如果来不及修改表结构或连接配置，可以使用COLLATE关键字强制统一排序规则。关键点在于：必须将COLLATE添加在具体字段或表达式之后，而不能仅写在别名上。这是新手最容易犯的错误。

正确的写法示例：

ON t1.code = t2.code COLLATE utf8mb4_0900_as_cs

如果字段本身是utf8mb4_unicode_ci，而你需要对齐到utf8mb4_0900_as_cs，则必须在两侧都添加：

ON t1.code COLLATE utf8mb4_0900_as_cs = t2.code COLLATE utf8mb4_0900_as_cs

这里还有几个容易忽视的细节：

• 子查询中也需要进行同样的处理：(SELECT code COLLATE utf8mb4_0900_as_cs FROM db2.t2)
• 不要使用CONVERT(code USING utf8mb4)——它仅更改字符集，不保证排序规则对齐，并且存在截断风险
• 如果字段是数字类型（例如用VARCHAR存储ID），但排序规则不同，仍然需要添加COLLATE。因为MySQL的排序规则比较逻辑会参与字符串等值判断

根本解决方案：通过ALTER TABLE同步字符集与排序规则

仅修改CHARACTER SET而不修改COLLATE，等于徒劳无功。MySQL实际比较的是排序规则，而非字符集本身。这一点必须牢记。

正确的语法必须同时指定两者：

ALTER TABLE db2.t2 MODIFY code VARCHAR(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs;

操作前务必做好以下准备：

• 首先使用SHOW CREATE TABLE db2.t2确认当前COLLATE值，再选择目标值，不要硬套utf8mb4_unicode_ci
• 大表执行会锁表（除非支持ALGORITHM=INPLACE），线上务必在低峰期操作
• 如果表包含外键、全文索引或生成列，MODIFY可能失败，需要提前处理依赖关系
• 修改完成后立即验证：SHOW FULL COLUMNS FROM db2.t2 LIKE 'code';，确认Collation列已更新

真正容易被忽略的是：在跨库场景下，两个数据库的默认COLLATE可能不同。即使你将所有字段都改为utf8mb4_0900_as_cs，只要连接层未对齐，下次更换客户端连接时，问题依然会出现。因此，连接配置与字段定义必须同步调整，缺一不可。