mysqldump 加 --single-transaction
能保证一致性，但仅对 InnoDB 有效
这是最常用也最容易被误用的方式。
--single-transaction会让
mysqldump在开始备份前启动一个 REPEATABLE READ 事务，之后所有表读取都基于该事务快照，避免锁表的同时获得逻辑一致的数据。
但注意：它只对 InnoDB 表起作用；MyISAM 或其他非事务引擎仍会触发
FLUSH TABLES WITH READ LOCK（除非显式禁用），导致全局只读阻塞。 必须确保数据库中所有待备份表都是 InnoDB，否则一致性无法保障 备份期间长事务可能拖慢 MVCC 清理，间接影响性能 如果备份耗时过长，而业务有大量更新，可能导致 undo log 膨胀或事务 ID 回卷风险
遇到混合引擎或需要强一致时，--lock-all-tables
是更稳妥的选择
当库中存在 MyISAM、ARCHIVE 或 MEMORY 表，或者你无法确认引擎类型时，
--single-transaction会自动退化为加全局读锁——但这个行为不透明，容易误判。直接使用
--lock-all-tables反而更可控。
它执行
FLUSH TABLES WITH READ LOCK，让所有引擎进入只读状态，然后逐个 dump 表。虽然会短暂阻塞写入，但能确保任意引擎组合下时间点完全一致。 锁持续时间 = 所有表 metadata 获取 + 文件写入总耗时，不是单个表锁 主从复制环境下，该锁会阻塞 SQL 线程，需避开复制延迟敏感时段 若备份过程中连接断开，锁不会自动释放，需人工检查
SHOW PROCESSLIST和
SELECT * FROM performance_schema.metadata_locks
物理备份（xtrabackup）比逻辑备份更适合大库一致性保障
对于百 GB 级以上 InnoDB 数据库，
mysqldump的逻辑导出+重放路径太慢，且恢复时无法跳过部分表。Percona XtraBackup 的热备机制在文件系统层面拷贝数据页，配合
--apply-log回滚未提交事务、前滚已提交事务，天然支持崩溃一致性。
关键点在于它不依赖 SQL 层事务隔离，而是利用 InnoDB 的 redo log 流水线和 checkpoint 位置实现精确时间点对齐。
备份开始时记录当前 LSN（Log Sequence Number），结束时再刷一次，保证日志覆盖整个备份窗口xtrabackup --backup过程中允许 DML，但不能执行 DDL（如
ALTER TABLE），否则可能引发备份失败或元数据错乱 恢复后必须运行
xtrabackup --prepare，否则数据文件处于“未合并”状态，MySQL 启动会拒绝加载
事务安全配置缺失会导致备份看似成功实则不可靠
即使用了
--single-transaction，如果 MySQL 实例本身没开启事务安全相关参数，备份仍可能丢失关键变更。典型问题包括：
binlog_format不是
ROW：语句级 binlog 在主从间重放时可能因函数、临时表等产生不一致，影响 PITR（Point-in-Time Recovery）可靠性
innodb_flush_log_at_trx_commit=0或
2：事务提交后日志未强制刷盘，主机宕机可能导致已备份的事务实际未持久化 未启用
sync_binlog=1：binlog 缓冲未同步到磁盘，与 InnoDB redo 不一致，GTID 或 position 定位失效
这些参数不直接影响
mysqldump命令是否报错，但决定了“备份那一刻”数据库实际处于什么状态——看起来一致，其实 redo、binlog、数据页三者之间已有裂痕。
