根本原因是源库和目标库列级COLLATE不一致，如utf8mb4_0900_ai_ci与utf8mb4_general_ci对emoji、重音字符等比较逻辑不同；需用SHOW FULL COLUMNS确认各列真实排序规则，逐列比对，并协同校准连接层character_set_client。
为什么迁移后 ORDER BY 结果变了？
根本原因是源库和目标库的列级 COLLATE 不一致，比如源表字段用的是 utf8mb4_0900_ai_ci，而目标库建表时没显式声明，MySQL 自动 fallback 到 utf8mb4_general_ci 或更老的默认值。这两种排序规则对 emoji、德语 ß、法语重音字符等的比较逻辑完全不同，ORDER BY 和 WHERE name = 'café' 这类操作就会出人意料。
如何查清当前字段实际生效的 COLLATE？
别只看 SHOW CREATE TABLE 里写的默认值，要确认每个字段的真实排序规则：
- 运行
SHOW FULL COLUMNS FROM table_name;，重点看Collation列，不是Charset - 对比源库和目标库同一张表的输出，逐列核对是否一致
- 如果某列显示为
NULL，说明它继承自表级定义；如果表级也没设，则继承自数据库级；最终兜底是服务器级collation_server
ALTER TABLE 时怎么安全指定 COLLATE？
直接改表或列的排序规则必须带完整字符集声明，否则 MySQL 可能静默忽略或报错：
- 改整张表（含所有文本列）：
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 只改单个字段：
ALTER TABLE t MODIFY COLUMN name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 注意：如果目标库是 MySQL 5.7，
utf8mb4_0900_ai_ci不可用，得换成utf8mb4_unicode_ci—— 否则会报Unknown collation - 大数据量表慎用
CONVERT TO，它会重建整张表，锁表时间长；可考虑分批MODIFY COLUMN+ 应用层灰度验证
应用层查询如何绕过隐式 COLLATE 冲突？
当无法立刻统一表结构，又急需修复某个 SQL 的排序/比较行为，可以在查询中显式指定：
- ORDER BY 时强制用某规则：
ORDER BY name COLLATE utf8mb4_unicode_ci - WHERE 比较时对齐：
WHERE name COLLATE utf8mb4_unicode_ci = '测试' COLLATE utf8mb4_unicode_ci - 但注意：加
COLLATE会让对应列索引失效，除非该列本身已建了对应排序规则的索引 - 临时方案仅用于救急，长期仍需统一元数据层的
COLLATE声明
utf8mb4_0900_ai_ci，只要客户端连接的 character_set_client 是 latin1，MySQL 就会在解析 SQL 时按 latin1 解码字符串字面量，导致 WHERE name = 'café' 中的 é 被错解——所以连接层编码和字段级 COLLATE 必须协同校准。 
