答案是MySQL字符集迁移需确保编码一致，防止乱码。首先确认当前数据库、表、列及服务器字符集设置，重点检查latin1与utf8混用情况；然后制定迁移到utf8mb4等目标字符集方案，并使用mysqldump按原字符集完整备份数据；接着修改导出文件中的字符集定义或将表结构转换为utf8mb4，通过导入或ALTER TABLE CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci完成转换；操作期间避免导出时使用错误字符集导致二次编码；最后验证数据无乱码，设置客户端连接SET NAMES 'utf8mb4'并配置应用连接参数charset=utf8mb4，确保全链路字符集统一，整个过程核心在于准确声明字符集、防止隐式转换，保障数据一致性。
MySQL字符集迁移是数据库运维中常见的需求，尤其在系统升级、跨平台迁移或支持多语言时。处理不当可能导致乱码、数据丢失或应用异常。核心思路是明确当前字符集，规划目标字符集，再通过导出、转换、导入等步骤安全迁移。
确认当前字符集配置
迁移前需全面了解现有环境的字符集设置：
- 查看数据库级别字符集：SHOW CREATE DATABASE db_name; 可看到数据库默认字符集
- 查看表和列的字符集：SHOW CREATE TABLE table_name; 检查表结构中的CHARACTER SET定义
- 查看服务器全局设置：SHOW VARIABLES LIKE 'character_set%'; 显示客户端、连接、结果等各环节字符集
重点关注character_set_database、character_set_server以及具体表和字段的编码。若存在latin1与utf8混用，需重点处理。
制定迁移目标与备份数据
常见目标是迁移到utf8mb4，以支持完整UTF-8（如emoji）。操作前必须完整备份：
- 使用mysqldump --single-transaction --routines --triggers --hex-blob --default-character-set=latin1 db_name > backup.sql 导出原始数据（注意指定原字符集）
- 若原为latin1，导出时不能用utf8，否则会二次编码导致乱码
- 备份完成后验证文件可读性，确保恢复路径畅通
修改表结构并重新导入
编辑dump文件或直接在新库中调整字符集：
- 将CREATE TABLE语句中的CHARACTER SET latin1替换为CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
- 也可在导入后执行ALTER语句：ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
- 该命令会同时转换表中所有字符型字段（CHAR、VARCHAR、TEXT等）
注意：ALTER操作可能锁表，建议在低峰期执行，大表考虑分批处理。
验证数据与调整连接配置
导入后需检查数据是否正常显示：
- 查询包含非ASCII字符的记录，确认无问号或乱码
- 设置客户端连接字符集一致：SET NAMES 'utf8mb4';
- 在应用连接串中添加charset=utf8mb4参数，确保全程编码统一
- 检查排序规则（collation）是否满足业务需求，如大小写敏感等
基本上就这些。关键是保持“导出—转换—导入”过程中字符集声明准确，避免隐式转换。
