不能保证全库一致性；仅对InnoDB表有效，需无DDL操作、关闭autocommit，且不适用于MyISAM或跨库场景，真正一致需FLUSH TABLES WITH READ LOCK+SHOW MASTER STATUS。
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 STATUS - MySQL 8.0+ 才默认包含，5.7 中需手动安装，兼容性需确认
真正保证一致性：为什么必须结合 FLUSH TABLES WITH READ LOCK + SHOW MASTER STATUS？
这是物理一致性+逻辑位点绑定的标准做法。加全局读锁能冻结所有引擎（包括 MyISAM），配合 SHOW MASTER STATUS 记录精确 binlog 坐标，后续恢复时可用 mysqlbinlog 补齐锁释放后的变更。
基于Intranet/Internet 的Web下的办公自动化系统，采用了当今最先进的PHP技术，是综合大量用户的需求,经过充分的用户论证的基础上开发出来的，独特的即时信息、短信、电子邮件系统、完善的工作流、数据库安全备份等功能使得信息在企业内部传递效率极大提高，信息传递过程中耗费降到最低。办公人员得以从繁杂的日常办公事务处理中解放出来，参与更多的富于思考性和创造性的工作。系统力求突出体系结构简明
容易踩的坑：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 补全。这个间隙无法消除，只能通过缩短锁持有时长、及时采集位点来收窄。
