mysqldump加--single-transaction不保证强一致仅对InnoDB表有效且依赖REPEATABLE READ隔离级别MyISAM表、DDL操作或隔离级别变更均破坏一致性。mysqldump 加 --single-transaction 不等于强一致很多人以为加了 --single-transaction 就能拿到全库一致性快照实际不是——它只对 InnoDB 表生效遇到 MyISAM 表、临时表、或者备份中途有 DDL比如 ALTER TABLE快照就失效了。更关键的是--single-transaction 依赖事务隔离级别为 REPEATABLE READ而某些 ORM 或中间件会悄悄改隔离级别导致 dump 出来的时间点不统一。实操建议先用 SELECT ENGINE, TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA your_db; 检查是否混用引擎备份前显式执行 SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;如果存在 MyISAM 表必须配合 --lock-all-tables会锁写不能只靠 --single-transaction避免在备份窗口内执行任何 DDL可用 SHOW PROCESSLIST 监控长事务阻塞GTID mysqldump --set-gtid-purgedON 才能准确定位起点单纯导出 SQL 文件恢复后无法知道这条数据对应主库哪个 GTID也就没法做后续的增量同步或校验。漏掉 --set-gtid-purgedON或设为 OFF会导致生成的 dump 文件里没有 SET GLOBAL.GTID_PURGED 语句恢复到新实例后 GTID 集为空binlog 位置完全脱钩。实操建议务必确认源库已开启 gtid_modeON 且 enforce_gtid_consistencyONdump 命令中显式加上 --set-gtid-purgedON默认值在新版 MySQL 中已是 AUTO但行为不稳定必须显式声明检查 dump 文件开头是否有类似 SET GLOBAL.GTID_PURGEDa1b2c3e4-5678-90ab-cdef-1234567890ab:1-100; 的行恢复时目标实例也需开启 GTID且 gtid_executed 必须为空否则报错 GTID_PURGED can only be set when GTID_EXECUTED is empty用 pt-table-checksum 校验前先停写或切读写分离流量pt-table-checksum 本身不锁表但它依赖主从复制延迟接近零才能比对准确。如果迁移后刚切流应用还在往旧库写、新库靠延迟同步checksum 结果全是“不一致”但这不是数据问题是时间差问题。 Zeemo AI 一款专业的视频字幕制作和视频处理工具