mysqldump 加 --single-transaction
能否保证全库一致性？
不能一概而论。它只对
InnoDB表有效，且前提是整个备份过程中没有执行
ALTER TABLE、
DROP TABLE、
RENAME TABLE等隐式提交 DDL；一旦发生，事务快照会失效，后续表将读取新状态，导致跨表数据不一致。
常见错误现象：
mysqldump --single-transaction备份出的订单表和用户表在恢复后出现外键关联断裂（例如订单里有
user_id=1001，但用户表里查不到该 ID）——这往往是因为备份中途有人删了用户又重建，或执行了表结构变更。 仅适用于
InnoDB，对
MyISAM或混合引擎库完全无效（会退化为表级锁） 必须关闭
autocommit=1，否则每个语句自动提交，快照无法维持 备份开始时获取的是一个时间点的事务 ID（
SELECT @@GLOBAL.GTID_EXECUTED可辅助验证），但不等于 GTID 一致性
用 mysqlpump
替代 mysqldump
是否更安全？
mysqlpump默认按库并行导出，且每个线程内部使用
--single-transaction，但它不保证库间一致性。比如同时备份
shop_db和
log_db，两个库的快照时间不同，若存在跨库事务（如业务写主库、日志写日志库），恢复后逻辑关系就断了。
使用场景：适合单库多表、无跨库依赖的系统；不适合微服务拆分后仍共用一套备份策略的环境。
并行导出加快速度，但增大了“时间窗口”，跨表/跨库不一致风险反而上升 不支持--master-data直接记录 binlog 位置，需额外执行
SHOW MASTER STATUSMySQL 8.0+ 才默认包含，5.7 中需手动安装，兼容性需确认
真正保证一致性：为什么必须结合 FLUSH TABLES WITH READ LOCK
+ SHOW MASTER STATUS
？
这是物理一致性+逻辑位点绑定的标准做法。加全局读锁能冻结所有引擎（包括
MyISAM），配合
SHOW MASTER STATUS记录精确 binlog 坐标，后续恢复时可用
mysqlbinlog补齐锁释放后的变更。
容易踩的坑：
FLUSH TABLES WITH READ LOCK会阻塞所有写入，且在高并发下可能被长事务卡住（
SHOW PROCESSLIST中看到
Waiting for table flush）；锁未释放前，任何
UNLOCK TABLES都无效。 执行前务必检查
SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED LIMIT 1，避免被隐藏长事务拖住 锁期间不能执行任何 DDL，否则会隐式解锁，导致后续
SHOW MASTER STATUS位点不可靠 备份完立即
UNLOCK TABLES，不要等压缩完成——锁持有时间越长，业务影响越大
FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS; -- 此时立刻记录 File 和 Position 字段值，例如： -- File: mysql-bin.000042, Position: 1987654 -- 然后执行 mysqldump（不带 --single-transaction） -- 最后解锁 UNLOCK TABLES;
恢复时怎么验证事务完整性？
单纯导入 SQL 文件不等于事务完整。如果备份中含
SET AUTOCOMMIT=0和大量
COMMIT，而目标库
sql_log_bin=0未关闭，会导致 binlog 写入混乱；若开启 GTID，还可能因
GTID_PURGED设置错误引发复制中断。
关键动作不是“导入成功”，而是“导入后能对上原始 binlog 位点”。建议恢复后立即比对：
检查SELECT COUNT(*)和
CHECKSUM TABLE结果是否与备份前一致（注意大表慎用
CHECKSUM） 若启用 GTID，恢复前执行
SET GLOBAL GTID_PURGED='xxx'，值来自备份时的
SHOW MASTER STATUS输出 用
mysqlbinlog --base64-output=DECODE-ROWS -v查看最近几条事件，确认关键 UPDATE/INSERT 时间戳与业务日志吻合
备份链路里最常被忽略的，是“锁释放到第一个 binlog 事件写入之间”的那几十毫秒——它不在任何快照里，也不在任何锁保护下，只能靠 binlog 补全。这个间隙无法消除，只能通过缩短锁持有时长、及时采集位点来收窄。
