mysqldump是最常用、最可控的迁移起点，但直接执行mysqldump -u root -p db_name > dump.sql后需用mysql -u root -p db_name < dump.sql导入。
mysqldump 是最常用、最可控的迁移起点，但直接执行 mysqldump -u root -p db_name > dump.sql 然后 mysql -u root -p db_name 很大概率失败——不是数据丢，而是字符集错、权限缺、锁表卡住、大表超时。
<h3>导出时加不加 <code>--single-transaction 决定是否锁表
对 InnoDB 表，--single-transaction 能在不锁表前提下保证一致性快照；但 MyISAM 表不支持该参数，会退化为全局读锁（FLUSH TABLES WITH READ LOCK），导致写入阻塞。生产环境务必确认存储引擎：
- 查表引擎：
SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db';</li> <li>只对 InnoDB 表用 <code>--single-transaction
；混合引擎库建议分表导出，或改用mydumper并发处理 - 加
--skip-triggers或--skip-routines可绕过触发器/存储过程兼容性问题（尤其跨版本时）
导入前必须检查目标库的 character_set_server 和 collation_server
源库是 utf8mb4，目标库默认是 latin1？那导入后所有 emoji 和中文都会变成 ???。别依赖 mysqldump 文件里的 SET NAMES —— 它只影响客户端连接，不改变表实际字符集。
- 导出前查源库：
SHOW VARIABLES LIKE 'character_set%';和SHOW CREATE DATABASE your_db; - 导入前设目标库：
ALTER DATABASE your_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; - 导入后逐表检查：
SHOW CREATE TABLE t1;，确保DEFAULT CHARSET=utf8mb4出现在建表语句末尾
mysql 命令导入大文件时容易中断或超时
默认 max_allowed_packet 是 4MB，导出文件超 50MB 就可能报错 Packets larger than max_allowed_packet are not allowed；同时网络传输或客户端超时也会中断。
- 导入前临时调高限制：
mysql --max-allowed-packet=512M -u root -p your_db - 禁用自动提交加速导入：
mysql -u root -p -e "SET autocommit=0; SOURCE /path/dump.sql; COMMIT;" your_db - 超 1GB 文件建议拆分或改用
mysqlpump（MySQL 5.7+）或myloader（配合mydumper输出）
迁移后必须验证的三件事，比“导入成功”更重要
日志显示 Query OK 不代表数据就对了。线上迁移踩过最多坑的是：主键重复、自增 ID 错位、外键约束失效、时间字段时区偏移。
- 行数核对：
SELECT COUNT(*) FROM t1;源/目标库分别执行，不能只信mysqldump最后一行的 “Dump completed” - 校验和抽查：
SELECT MD5(GROUP_CONCAT(CONCAT_WS('|', id, name, updated_at) ORDER BY id)) FROM t1;—— 避免因 NULL 值或排序差异导致误判 - 连通性测试：用应用账号连接目标库，执行一条带事务的写操作（如
INSERT ...; ROLLBACK;），确认权限、SSL 设置、SQL_MODE 兼容性都到位
