必须文本替换dump文件中的旧排序规则：将utf8mb4_unicode_520_ci改为utf8mb4_0900_ai_ci，删改CHARSET=utf8mb4 COLLATE=utf8_general_ci等非法组合，并统一库表字段collation为utf8mb4_0900_ai_ci。
恢复时遇到“Unknown collation”错误怎么救
这是从 MySQL 5.7 或更早版本导出的 SQL 文件，在 8.0 中导入时报的典型错误，比如 Unknown collation: 'utf8mb4_unicode_520_ci' 或 COLLATION 'utf8_general_ci' is not valid for CHARACTER SET 'utf8mb4'。根本原因是 dump 文件里硬编码了 8.0 不认识的旧排序规则，或者把已废弃的 utf8 字符集写进了建表语句。
- 先用文本编辑器或
sed批量替换：把所有utf8mb4_unicode_520_ci换成utf8mb4_0900_ai_ci - 删掉或重写所有含
CHARSET=utf8mb4 COLLATE=utf8_general_ci的行——utf8_general_ci在 utf8mb4 字符集下根本不合法，必须改为utf8mb4_0900_ai_ci或utf8mb4_unicode_ci - 如果 dump 文件里有
CREATE DATABASE ... DEFAULT CHARSET=utf8，要改成DEFAULT CHARSET=utf8mb4，否则 8.0 会拒绝解析
还原后报 ERROR 1267：Illegal mix of collations 怎么定位
导入成功但一查就崩，说明字段级 collation 混用了。MySQL 8.0 对 JOIN、FIND_IN_SET()、子查询等操作强制校验两边 collation 是否一致，不匹配就直接报错，不会静默转换。
- 执行
SELECT TABLE_NAME, COLUMN_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'your_db' AND COLLATION_NAME NOT IN ('utf8mb4_0900_ai_ci');，找出所有非 8.0 默认的列 - 特别注意
FIND_IN_SET()的两个参数：第一个是字段（可能带旧 collation），第二个是变量或字符串字面量（默认继承 session 的 collation，通常是utf8mb4_0900_ai_ci）——两边不一致就会触发错误 -
JSON_VALUE()也一样，必须显式声明返回类型和 collation，比如JSON_VALUE(data, '$.field' RETURNING CHAR(100) COLLATE utf8mb4_0900_ai_ci)
ALTER TABLE CONVERT TO 和 MODIFY 到底该用哪个
CONVERT TO 改的是整张表的默认 collation，但不会覆盖已有字段上显式声明的旧 collation；MODIFY 是精准修正单个字段，必须带完整类型定义。
- 先跑
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;，它会让新字段继承这个 collation，但对已有字段中显式写了COLLATE utf8mb4_general_ci的列无效 - 再针对这些“钉子户”字段单独执行：
ALTER TABLE t MODIFY col VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - TEXT 类型字段也要查 —— 它们同样能带 collation，且参与比较，漏掉会导致后续 JOIN 失败
- 大表操作前加
SET SESSION innodb_lock_wait_timeout = 300;，避免 phpMyAdmin 或宝塔面板超时中断
UNIQUE 索引突然失效或报 Duplicate entry 怎么办
同一字符串在 utf8mb4_general_ci 和 utf8mb4_0900_ai_ci 下可能被判定为“相等”或“不等”，导致唯一约束行为突变。这不是数据错了，是 collation 切换后比较逻辑变了。
- 还原后立刻验证关键索引字段的行为：
SELECT * FROM t WHERE col = '张三' COLLATE utf8mb4_unicode_ci;和COLLATE utf8mb4_0900_ai_ci结果是否一致 - 如果源库用的是
utf8mb4_bin建的 UNIQUE 索引，目标库却按utf8mb4_0900_ai_ci解析，小写/大写可能被当成不同值，插入时就会撞车 - 修复方式不是删索引重挂，而是先统一字段 collation，再
ALTER TABLE t DROP INDEX idx_name; ALTER TABLE t ADD UNIQUE INDEX idx_name (col);
真正麻烦的不是改 collation 这一步，而是你得确认业务 SQL 里所有隐式比较点——比如 ORDER BY、GROUP BY、视图定义、存储过程里的临时表——它们全依赖 collation 行为。一个没扫到，上线就出数据逻辑偏差。
