跨库迁移乱码需先确认源库和目标库的character_set_database是否一致，不一致则重建目标库并设置为utf8mb4；再检查Navicat数据传输中是否勾选“Convert character set”；最后验证字段Collation及连接层字符集是否均为utf8mb4。
确认源库和目标库的 character_set_database 是否一致
跨库迁移时乱码，第一眼要查的不是表或字段，而是两个库各自的默认字符集。navicat 的「数据传输」或「结构同步」功能不会自动转换字符集，它只按字节原样搬运。如果源库是 utf8mb4，目标库是 latin1 或 utf8（即 utf8mb3），那中文字段一写进去就变 ???。
- 在源库执行：
SHOW VARIABLES LIKE 'character_set_database';，记下返回值 - 在目标库执行同样语句，对比是否一致；不一致就说明迁移前没建对库
- 目标库若为
latin1或空值（继承 server 默认），必须重建：用CREATE DATABASE target_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;替代直接右键「新建数据库」 - 已有目标库无法用
ALTER DATABASE改character_set_database，这是只读变量，强行改会失败
检查 Navicat 数据传输向导里是否勾选了「转换字符集」
Navicat 的「数据传输」对话框里有个容易被忽略的开关：「Convert character set」。它控制是否在迁移过程中对字段内容做 CONVERT(... USING utf8mb4) 式重编码。不勾选 = 字节直拷，勾选 = 尝试转码（但仅对支持的类型生效）。
- 该选项默认关闭，必须手动勾选；位置在「高级」页签底部，不是「选项」或「设置」里
- 勾选后，Navicat 会尝试把源字段按其当前字符集解码，再以目标字段字符集重新编码 —— 这要求源字段本身声明了正确字符集，否则仍会失败
- 若源表字段是
CHARACTER SET latin1但存了 UTF-8 字节（常见于历史脏数据），勾选此选项反而导致二次乱码，此时应先清洗源数据 - 建议优先确保源/目标库、表、字段三级字符集统一，再勾选此项；否则宁可关掉，靠后续
ALTER TABLE ... MODIFY COLUMN人工修正
验证目标表字段的 Collation 是否真正生效
即使目标库建对了、传输向导也勾了转换，最终查出来还是问号，大概率是字段级元数据没更新。特别是 TEXT 类型字段，CONVERT TO CHARACTER SET 命令有时不覆盖它们。
- 运行：
SHOW FULL COLUMNS FROM `your_table`;，重点看Collation列 —— 必须是utf8mb4_unicode_ci或类似utf8mb4_0900_as_cs，不能是latin1_swedish_ci或空 -
TEXT、MEDIUMTEXT、JSON字段需单独处理：ALTER TABLE your_table MODIFY COLUMN content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 别信
SHOW CREATE TABLE末尾的DEFAULT CHARSET=utf8mb4—— 它只管新字段，默认不改已有字段的定义 - 迁移后立刻执行
SELECT HEX(column_name) FROM your_table LIMIT 1;，若返回如E4B8ADE69687（UTF-8 编码的“中文”），说明字节正确；若返回3F3F3F3F（四个问号的十六进制），说明写入时已被替换成 ?
连接层未初始化 utf8mb4 导致 SELECT 显示异常
迁移完成、字段也改好了，但 Navicat 查询窗口里 SELECT 出来仍是方块或问号？问题出在连接初始化没生效。数据本身是对的，只是客户端读的时候用了错的编码解。
- 右键目标库连接 →「编辑连接」→「高级」→ 勾选「Use MySQL character set」，下拉框选
utf8mb4（注意不是utf8） - 在「初始化命令」框里填：
SET NAMES utf8mb4;，保存并断开重连 - 重连后立即执行：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;，三个值必须全为utf8mb4 - 如果其中一个是
utf8或latin1，说明初始化命令没执行或被覆盖 —— 检查 Navicat 是否启用了「自动提交」或「连接池」，这些可能绕过初始化
