一致性快照备份是什么
--single-transaction 让 mysqldump 在一个可重复读事务里读取数据，导出期间看到的是事务开始那一刻的一致快照，因此不需要长时间锁表，InnoDB 表的写入也不受影响。前提是被导出的表都在事务引擎上，MyISAM 这类非事务表不受该机制保护。
基本信息
| 原理 | 开启事务并读取一致性快照，导出过程走 MVCC 读视图 |
|---|---|
| 适用 | InnoDB 等事务引擎 |
| 不适用 | MyISAM、MEMORY 等非事务表仍可能不一致 |
| 常见搭配 | --source-data=2 记录位点，--routines 与 --events 补全对象 |
一致性热备
一致性热备
mysqldump -u root -p --single-transaction --source-data=2 \
--routines --events --triggers \
--databases appdb > appdb-consistent-$(date +%F).sql
# 产物开头可见位点注释，供后续从该坐标回放 binlog
grep -n "CHANGE REPLICATION SOURCE TO" appdb-consistent-$(date +%F).sql相关参数对照
| 参数 | 作用 | 注意 |
|---|---|---|
| --single-transaction | 走事务快照，不锁表 | 仅对事务引擎有效 |
| --lock-all-tables | 全局读锁保证一致 | 会阻塞写入，不用于在线库 |
| --source-data=2 | 记录位点 | 取位点时短暂加锁 |
| --flush-logs | 导出前切换日志文件 | 便于把归档切在备份点之后 |
使用要点
- 导出时长越长，回滚段与历史版本保留压力越大，大实例应安排在业务低峰
- 导出期间不要执行 DDL：建表删表会隐式提交，破坏快照一致性
- 临时表与混合引擎的库要单独确认：非事务表在快照之外仍可能被改动
- 与其他参数组合时注意顺序与互斥关系，例如与加锁选项同时使用不会得到预期效果
- 导出完成后立即核对产物大小与关键表是否存在，避免得到一份看似正常的空文件
导出期间避免对目标库执行 DDL（ALTER、DROP 等），DDL 会隐式提交并破坏快照一致性，得到的产物可能跨越多个时间点。
该参数与 binlog 位点记录配合，才构成可以做时间点恢复的完整逻辑备份；只有数据没有位点时，恢复精度只能到备份完成时刻。
不适用与该避开的情形
- 库中混有 MyISAM 表：这些表在导出期间仍可能被修改，得到不一致数据
- 需要导出系统库或权限表：这类表自身不是 InnoDB，应单独处理
- 正在进行结构变更：DDL 提交会打断快照，变更应与备份错峰安排
- 实例上存在超长事务：会显著拉长历史版本链，加剧回滚段占用