mysqldump导出必须加--single-transaction和--master-data=2，否则binlog位置与数据不一致，导致从库复制启动失败；若启用GTID还需加--set-gtid-purged=ON，且应显式指定库名、避免--all-databases，从库导入前须STOP SLAVE; RESET SLAVE ALL; 并清空业务库。
mysqldump导出时必须加 --single-transaction 和 --master-data=2
不加这两个参数，导出的数据和 binlog 位置对不上，从库启动复制后大概率报 Could not find first log file name in binary log index file 或直接跳过大量事务。前者是因为没记录主库当前 binlog 文件名和偏移，后者是因为事务不一致导致 GTID 或 position 复制断裂。
实操建议：
-
--single-transaction保证 InnoDB 表一致性快照（但对 MyISAM 无效，所以务必确认表引擎） -
--master-data=2把CHANGE MASTER TO所需的MASTER_LOG_FILE和MASTER_LOG_POS作为注释写在 dump 文件开头 - 如果主库开了 GTID，还要额外加
--set-gtid-purged=ON（默认值），否则从库导入后可能因 GTID 集合为空而拒绝启动复制 - 避免用
--all-databases导出：它会把mysql系统库也 dump 进来，而其中的gtid_executed、slave_master_info等表在从库上不能直接覆盖，容易引发冲突
从库导入前要先关掉复制线程并清空旧数据
很多人 dump 导入后直接 start slave，结果报 Slave has more GTIDs than the master 或主键冲突。根本原因是：旧从库可能已有部分数据，或残留了之前复制状态，和新 dump 的起始点打架。
正确做法是彻底重置：
- 执行
STOP SLAVE;，再RESET SLAVE ALL;（注意不是RESET SLAVE，后者不删master.info文件） - 删除从库所有业务库（
DROP DATABASE），不要用TRUNCATE或DELETE—— 它们不重置 auto_increment、不清理索引统计，且无法处理新增表 - 导入前确认从库
server_id已改且唯一，否则主库 binlog 里会漏记该从库的事件 - 导入命令别用
source，用mysql -u root -p ，避免客户端缓冲区溢出或字符集错乱
导入完成后必须手动执行 CHANGE MASTER TO 再 start slave
dump 文件里的 CHANGE MASTER TO 注释只是参考，不能直接依赖。因为 dump 时间和实际导入完成时间之间存在延迟，主库 binlog 可能已滚动；更关键的是，如果你用的是 GTID 复制模式，这行语句根本无效，必须用 SET GLOBAL gtid_slave_pos = 'xxx' 替代。
判断依据看主库 SHOW MASTER STATUS 和 dump 文件头的注释是否一致：
- 如果是基于 position 复制：比对 dump 注释里的
MASTER_LOG_FILE和MASTER_LOG_POS是否仍有效（查主库SHOW BINARY LOGS确认文件是否存在） - 如果是 GTID 复制：从 dump 文件里提取
SET @@GLOBAL.gtid_purged='...'那行，导入后在从库执行它，再CHANGE MASTER TO MASTER_AUTO_POSITION = 1 - 无论哪种模式，执行
START SLAVE后立刻查SHOW SLAVE STATUS\G，重点盯Seconds_Behind_Master、Slave_IO_Running、Slave_SQL_Running三项
大库导入期间主库性能抖动明显，怎么压低影响
mysqldump 默认单线程全表扫描 + 全量锁表（即使有 --single-transaction，对大表的 MVCC 快照生成本身也吃 CPU 和 buffer pool），主库 QPS 下降、响应变慢很常见。
缓解手段有限但有效：
- 加
--skip-triggers和--skip-routines：触发器和存储过程不会被复制到从库，导出它们纯属浪费 IO - 用
--compress减少网络传输量（尤其跨机房时），但会增加主库 CPU 开销，需权衡 - 避开业务高峰，用
--no-autocommit --skip-extended-insert让导入更快（减少从库解析压力），但这会让 dump 文件变大，不推荐超 10GB 场景 - 真正的大库（>100GB）别硬扛 mysqldump，考虑
Percona XtraBackup物理备份 +innobackupex --apply-log，速度差一个数量级
最容易被忽略的一点：dump 命令里没指定 --databases 时，默认导出所有库，包括你根本不想同步的测试库、日志库——务必显式列出要同步的库名，比如 mysqldump --databases db1 db2 ...。
