一致性快照备份
单事务备份参数是 InnoDB 场景做逻辑备份的必备选项：它在导出开始时开启一个可重复读事务，之后所有表的数据都来自同一个快照，因此导出过程中的写入不会造成表间数据错位，也不会阻塞业务写入。要注意它只对事务引擎生效——库里若仍有 MyISAM 这类非事务表，那部分数据的一致性没有保障。
基本信息
| 用途 | 不锁表的一致性备份 |
|---|---|
| 适用引擎 | 仅 InnoDB，非事务引擎不提供保护 |
| 典型命令 | mysqldump --single-transaction --skip-lock-tables |
| 配合参数 | 逐行读取降低内存占用，导出存储程序与触发器 |
| 快照时长 | 从导出开始持续到结束，导出越久保留越久 |
| 副作用 | 会让逐表加锁选项失效 |
典型使用场景
- 线上库例行备份：不阻塞写入，可以安排在业务时段内执行
- 主从环境下在从库上做逻辑备份，进一步降低对主库的影响
- 上线前变更兜底：变更前打一份快照导出作为回退依据
- 单库迁移到新实例
- 数据抽样导出到测试环境
- 需要位点的场景：配合位点参数，备份可继续用于搭建复制
线上标准写法
线上标准写法
mysqldump -uroot -p --single-transaction --skip-lock-tables \
--quick --routines --events --triggers \
--default-character-set=utf8mb4 \
--databases appdb > appdb_$(date +%F).sql # 按库备份，恢复时可自动建库
grep -c 'CREATE TABLE' appdb_$(date +%F).sql # 粗略核对导出表数量备份前检查
备份前检查
SELECT COUNT(*) AS myisam_tables # 混有非事务引擎表时要单独处理
FROM information_schema.tables
WHERE table_schema='appdb' AND engine <> 'InnoDB';
SHOW VARIABLES LIKE 'transaction_isolation'; # 确认隔离级别符合预期参数组合与效果
| 参数 | 作用 | 注意 |
|---|---|---|
| --single-transaction | 开启一致性快照，不锁表 | 仅对 InnoDB 生效 |
| --skip-lock-tables | 显式关闭逐表加锁 | 与快照参数一起用，避免误锁 |
| --quick | 逐行流式读取 | 大表必备，降低客户端内存占用 |
| --routines --events --triggers | 导出存储程序与触发器 | 默认不导，最容易被遗漏 |
| --set-gtid-purged | 控制是否写入 GTID 信息 | 从库恢复前需评估 |
| --flush-logs | 导出前切换一次二进制日志 | 便于定位位点 |
| --source-data=2 | 把位点写进文件注释 | 8.0.26 起用新名称，旧名仍兼容 |
备份期间尽量避免在线改表（ALTER、TRUNCATE）：DDL 需要元数据锁，可能等住备份进程，也会破坏快照的一致性语义。
该选项只保护事务引擎：库里混有非事务表时，那部分数据仍会被导出期间的写入影响，发现存量非事务表应尽快安排改造。
快照在整个导出期间保持不释放，导出时间越长，实例需要维护的历史版本越多，回滚段与历史链表压力随之上升，备份任务应有人看耗时。
一致性备份检查清单
- 确认目标表都是事务引擎，非事务表单独安排
- 导出与恢复使用同一个字符集参数，避免中文乱码
- 大表导出加逐行读取，避免客户端内存被吃满
- 导出时段与业务高峰错开，减少 IO 争用
- 导出后核对表数量与文件大小，并做一次抽样恢复验证
- 记录备份位点，为后续搭建复制或时间点恢复做准备
在从库上做逻辑备份能显著降低对主库的影响，但要确认从库的复制延迟：延迟过大时备份出来的数据本身就落后于主库，恢复口径要以备份位点为准。