mysqldump --single-transaction不足以支撑生产回退，因其仅保障InnoDB表一致性快照、不记录binlog位置、且还原时无法处理结构冲突。
不能靠“同步完再看”来赌生产环境的稳定性。全量同步本身不危险，危险的是同步后无法快速、精确、可验证地回退——尤其当表结构变更和数据变更混在一起时。
为什么 mysqldump --single-transaction 不足以支撑生产回退
很多人默认用 mysqldump -u root -p --single-transaction db_name > backup.sql 做同步前备份，但这个操作在真实生产中存在三个硬伤：
- 它只保证 InnoDB 表的一致性快照，如果库中混有 MyISAM 表（比如系统日志表），备份期间这些表仍可能被写入，导致备份不一致；
- 它不记录 binlog 位置，无法与主从复制链对齐，后续若需基于时间点回退或切换从库，缺少坐标依据；
- 还原时若目标库已有同名表且结构不同（比如新增了 NOT NULL 字段），
mysql -u root -p db_name 会直接报错中断，而不是跳过或兼容处理。
真正可用的备份命令至少要加 --master-data=2 和 --routines，并确认 binlog_format = ROW 已启用。
全量同步过程中必须冻结的三类写操作
同步不是“把数据搬过去就完事”，而是确保源和目标在关键窗口期处于确定状态。以下操作必须在同步启动前协调停用：
- 应用层定时任务：如凌晨跑的统计脚本、归档 Job，它们可能在同步中途修改源库，造成目标库数据“多出一段”；
- DBA 手动 DML：包括
UPDATE、DELETE、TRUNCATE，哪怕只执行一条，也会破坏--single-transaction的一致性边界； - DDL 变更：任何
ALTER TABLE都会隐式提交事务并阻塞mysqldump，导致备份卡住或失败，且目标库结构将与备份不匹配。
建议用 FLUSH TABLES WITH READ LOCK（配合 --lock-all-tables）短时加全局读锁，比依赖应用停服更可控，但需注意锁持有时间不能超过业务容忍阈值。
回退不是“还原备份”，而是“按粒度选择还原路径”
遇到问题时，第一反应不该是“重跑备份”，而应判断影响范围：
- 仅结构错误（如误加了
NOT NULL字段）：用ALTER TABLE ... DROP COLUMN或RENAME TABLE切换备份表，毫秒级恢复，无需停服； - 部分表数据错乱（如只同步了订单表，但没同步用户表）：从全量备份中
grep出对应CREATE TABLE和INSERT片段，单独导入，避免整库覆盖； - 全库逻辑污染（如误执行
UPDATE ... SET status = 1 WHERE 1）：此时必须依赖带--master-data=2的备份 +mysqlbinlog定位误操作起始 position，用STOPAT方式回放至出错前一刻。
最常被忽略的一点：回退脚本本身必须提前在测试环境跑通，包括权限校验、字符集转换（如源库 utf8mb4_0900_as_cs，目标库仍是 utf8mb4_general_ci）、外键约束开关顺序。线上执行时，没人会等你现场 debug 字符集报错。
