数据库迁移 字符集问题 解决UnKnown collat​ion和UnKnown character set报错的方法

🛠️ 数据库迁移翻车实录：手把手解决字符集报错（Unknown collation/character set）

场景还原：
凌晨3点，你喝着第三杯咖啡☕，正准备将测试环境的MySQL数据迁移到生产服务器，突然终端弹出血红报错：

ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci'  
ERROR 1115 (42000): Unknown character set: 'utf16le'  

手里的咖啡突然不香了…别慌！这篇指南能让你10分钟内搞定问题！

🔍 为什么会出现这些报错？

根本原因是数据库版本差异：

• 高版本MySQL（如8.0+）新增的字符集/排序规则在低版本（如5.7）不存在
• 不同数据库厂商（如MySQL vs MariaDB）对字符集的支持不同

常见触发场景：

• 从云数据库（如AWS RDS MySQL 8.0）导出到本地MySQL 5.7
• 用新版MySQL Workbench导出的SQL文件在旧环境执行

🧰 解决方案大全

方案1：修改SQL文件（适合少量报错）

📌 适用场景：只有个别不支持的字符集/排序规则

-- 用文本编辑器全局替换（示例）  
utf8mb4_0900_ai_ci → utf8mb4_general_ci  
utf16le → utf8mb4  

💡 技巧：用VS Code的「正则替换」批量处理

COLLATE=utf8mb4_\w+ → COLLATE=utf8mb4_general_ci  

方案2：导出时指定兼容格式（推荐✨）

使用mysqldump时添加参数：

mysqldump --default-character-set=utf8mb4 \  
          --skip-set-charset \  
          --column-statistics=0 \  
          db_name > backup.sql  

关键参数说明：

• --skip-set-charset：不写入SET NAMES语句
• --column-statistics=0：避免MySQL 8.0+的统计信息报错

方案3：临时修改目标数据库配置（应急用）

在导入前执行：

-- 将不支持的字符集映射到已知字符集  
SET @@global.collation_server = 'utf8mb4_general_ci';  
SET @@global.character_set_server = 'utf8mb4';  

⚠️ 注意：这会影响后续新建表的默认配置

🛠️ 进阶排查技巧

查看数据库支持的字符集

SHOW CHARACTER SET;  -- 查看所有字符集  
SHOW COLLATION;      -- 查看所有排序规则  

版本兼容性速查表（2025-08最新）

💡 防坑小贴士

1. 迁移前做校验：用mysqlcheck --all-databases检查兼容性
2. 统一版本环境：尽量保证导出/导入的MySQL主版本号一致
3. 记录操作日志：📝 记下所有修改过的字符集，方便回滚

🌟 终极解决方案

如果条件允许，升级目标数据库版本！MySQL 5.7已于2023年停止官方支持，新版本对Unicode的支持更完善（而且性能提升超多🚀）。

遇到其他奇葩字符集问题？试试这个万能命令：

iconv -f ORIGINAL_CHARSET -t UTF-8 backup.sql > fixed_backup.sql