不一定，但必须控制写入一致性；mysqldump –single-transaction 可在不锁表前提下获取一致快照（仅innodb），需避免长事务、ddl操作及myisam表混用。
用 mysqldump 做增量备份前必须停写吗？
不一定，但必须控制写入一致性。直接跑 mysqldump --single-transaction 可以在不锁表前提下获取一致快照（仅限 InnoDB），前提是事务隔离级别没被显式降级、且没有长事务阻塞 MVCC 清理。
常见错误是 dump 过程中应用持续执行 ALTER table 或大事务更新，导致 mysqldump 等待 FLUSH TABLES WITH READ LOCK 超时失败，或 dump 出的数据实际已过期。
- 务必在迁移前检查
SHOW PROCESSLIST，杀掉运行超 30 秒的写事务 - 避免在 dump 期间执行
DROP TABLE、TRUNCATE TABLE，这类操作会打破--single-transaction保证 - 如果库中混用 MyISAM 表，
--single-transaction失效，必须配合--lock-all-tables，此时需业务短暂停写
pt-online-schema-change 能否用于全库迁移？
不能。它是单表 DDL 工具，不是数据迁移工具。它的作用是在不锁原表前提下完成字段增删、索引调整等，底层靠触发器同步增量变更，但不负责跨实例复制或初始数据拉取。
误用场景：有人想用它把旧库 A 的所有表“逐个在线改写”到新库 B，结果发现无从指定目标实例、无法处理外键依赖、更不管理 binlog 位点对齐。
- 真正需要的是
pt-online-schema-change+mysqldump+mysqlbinlog组合：先 dump 全量，再用 pt 工具在源库做平滑 DDL，最后靠 binlog 回放追平 - 若目标库已启用 GTID，必须确保源库也开启，并在 dump 时加
--set-gtid-purged=ON，否则恢复后复制关系无法建立 - 触发器在高并发下有性能损耗，观察
Threads_running和Innodb_rows_inserted指标，必要时降低--chunk-size
用 mysqlbinlog 实时追平数据时，如何避免主从延迟放大？
关键在解析位置和重放节奏。直接 mysqlbinlog --read-from-remote-server 拉取并 pipe 给目标库，容易因网络抖动或目标写入慢导致积压，进而拖垮整个迁移窗口。
推荐做法是分段拉取 + 本地暂存 + 控制重放速率：
- dump 结束后立刻记录源库
SHOW MASTER STATUS的File和position，作为 binlog 起始点 - 用
mysqlbinlog --stop-position分 5–10 分钟一段拉取，每段保存为本地文件，避免长连接中断 - 重放时加
--skip-slave-start并用SET session innodb_lock_wait_timeout = 2防止死锁卡住整条流 - 监控目标库
Seconds_Behind_Master，一旦 >60 秒，暂停下一段重放，人工检查是否有大事务或锁冲突
切换流量前，如何验证新库数据完全一致？
不能只比行数或 checksum 表头。InnoDB 的 MVCC 版本、删除标记、二级索引碎片都会导致 CHECKSUM TABLE 不一致，即使数据逻辑相同。
真实有效的校验必须基于业务主键或唯一键逐行比对，且覆盖 delete 状态：
- 用
pt-table-checksum在源库生成校验和，再用pt-table-sync对比目标库——但要求两库结构完全一致、且目标库必须可写 - 对核心表，手动抽样：按主键范围分片（如
id BETWEEN 10000 AND 20000），在源/目标库分别select id, col1, col2, updated_at FROM t WHERE ... ORDER BY id，用diff比较输出 - 特别注意
timestamp字段：MySQL 5.6+ 默认带时区转换，若源/目标时区配置不同，即使值一样，SELECT输出也可能不同
最易被忽略的是外键约束状态和 auto_increment 值——切换前必须在目标库执行 ALTER TABLE t AUTO_INCREMENT = N，N 是源库当前最大值 +1，否则插入会报主键冲突。