--single-transaction适用于纯InnoDB库，保证一致性且不停写；含MyISAM或引擎不确定时须用--lock-all-tables，以全局锁换强一致性，但业务写入暂停。
mysqldump 导出时加 --single-transaction 还是 --lock-all-tables
跨机全量迁移，核心矛盾是「数据一致性」和「业务停写时间」的权衡。用 mysqldump 时，--single-transaction 是默认推荐，但它只对 InnoDB 表有效，且依赖事务隔离级别为 REPEATABLE READ（MySQL 默认）。一旦库中混有 MyISAM 表，或者你不确定引擎类型，--single-transaction 就会失效——导出过程中其他连接仍可写入，导致主从不一致。
这时候必须切到 --lock-all-tables，它会执行 FLUSH TABLES WITH READ LOCK，全局只读，保证快照一致性。但代价是：锁表期间所有写操作阻塞，业务写入暂停，停机窗口取决于导出耗时。
- 确认引擎：运行
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db';，查清是否全是 InnoDB - 如果含 MyISAM 或不确定，别犹豫，用
--lock-all-tables，哪怕多停几分钟 - 导出前先关掉 binlog 写入（临时）：
SET sql_log_bin = 0;，避免 dump 过程产生大量日志 - 导出命令示例：
mysqldump -h source_host -u user -p --databases mydb --single-transaction --routines --triggers --events > backup.sql
导入目标库前要不要删库重建
直接 DROP DATABASE 再 CREATE DATABASE 最干净，但风险高：万一导入失败或脚本中断，库就没了。更稳妥的做法是保留原库结构，用 mysqldump 的 --no-create-db 和 --no-create-info 跳过建库建表语句，只导数据；再手动确认目标库表结构一致后，用 mysql 命令导入。
但注意：如果源库用了自定义字符集（比如 utf8mb4_0900_as_cs），而目标 MySQL 版本低于 8.0.17，导入会报错 Unknown collation: 'utf8mb4_0900_as_cs'。这时候必须提前替换 dump 文件里的 collation 定义，或升级目标实例。
- 检查源库默认字符集：
SHOW CREATE DATABASE mydb; - 对比目标 MySQL 版本支持的 collation：
SELECT * FROM information_schema.collations WHERE collation_name = 'xxx'; - 批量替换 dump 文件（Linux）：
sed -i 's/utf8mb4_0900_as_cs/utf8mb4_unicode_ci/g' backup.sql - 导入时加
--default-character-set=utf8mb4，避免客户端编码干扰
大库（>50GB）导入慢得离谱，怎么加速
默认 mysql 客户端导入是单线程、逐行执行 SQL，遇到大表 insert 大量数据，速度可能只有几 MB/min。根本原因是：每条语句都走完整事务流程 + 日志刷盘 + 索引重建。
提速关键不是换工具，而是关掉非必要开销。导入前在目标库执行：SET unique_checks=0; SET foreign_key_checks=0; SET autocommit=0;，导入完成后统一提交并恢复检查。这能减少索引维护次数和外键校验开销，实测提升 3–5 倍。
- 导入命令加
--force避免一条错就退出，方便后续排查 - 用
pv监控导入进度：pv backup.sql | mysql -u user -p target_db - 如果磁盘 I/O 是瓶颈，确认
innodb_flush_log_at_trx_commit=2（非 1），牺牲一点持久性换速度 - 导入完成后务必运行
ANALYZE TABLE更新统计信息，否则后续查询执行计划可能不准
迁移后主从延迟飙升甚至复制中断
全量导入本身不会触发复制，但如果你是在主库上 dump、在从库上导入，又没关掉从库的 SQL 线程，导入的 DML 会被从库当成“自己执行的语句”重放，和主库 binlog 冲突，导致 Slave_SQL_Running_State 卡在 Waiting for dependent transaction to commit 或直接报错 Could not execute Write_rows event on table...。
正确做法是：在从库导入前，先停掉复制：STOP SLAVE;，导入完成后再 START SLAVE;。但要注意，导入期间主库产生的新 binlog 位点，从库重启后会自动追，只要网络通、权限对、GTID 模式配置一致，就能续上。
- 检查 GTID 模式：
SELECT @@gtid_mode, @@enforce_gtid_consistency;，两边必须完全一致 - 导入前确认从库没有开启
read_only=ON（否则导入会报错The MySQL server is running with the --read-only option） - 导入后立刻查
SHOW SLAVE STATUS\G，重点看Seconds_Behind_Master和SQL_Delay是否归零 - 如果延迟持续不降，大概率是导入时没关
autocommit，导致每个 insert 都单独提交，生成海量小事务，拖慢 relay log 回放
真正麻烦的不是迁移动作本身，而是迁移前后对字符集、GTID、只读模式这些隐性配置的连带影响。一个 collation 不匹配，可能让应用查不到数据；一次 read_only 忘关，整场导入就卡死。这些点不显眼，但出问题时最难定位。
