mysqldump是最常用、最可控的迁移起点，但直接执行mysqldump -u root -p db_name > dump.sql后需用mysql -u root -p db_name

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';

• 只对 InnoDB 表用 --single-transaction；混合引擎库建议分表导出，或改用 <code>mydumper 并发处理
• 加 --skip-triggers 或 --skip-routines 可绕过触发器/存储过程兼容性问题（尤其跨版本时）

导入前必须检查目标库的 character_set_server 和 collation_server

源库是 utf8mb4，目标库默认是 latin1？那导入后所有 emoji 和中文都会变成 ???。别依赖 mysqldump 文件里的 SET NAMES —— 它只影响客户端连接，不改变表实际字符集。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 导出前查源库：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 兼容性都到位

真正麻烦的从来不是“怎么导”，而是“导完怎么确认没丢、没乱、没偏”。字符集、自增起始值、时区、SQL_MODE 这些配置项一旦漏查，上线后的问题往往要花几倍时间回溯。