MySQL mysqldump --single-transaction 导出 InnoDB：一致性边界与锁影响

线上数据库要做逻辑备份时，最容易误解的一点是：mysqldump --single-transaction 不是给所有表加一把“全局时间锁”，而是让 InnoDB 在导出前建立一个一致性读视图。只要表主要使用 InnoDB，业务读写通常可以继续；但混合存储引擎和导出期间的 DDL，会把这个结论推向边界。

把 --single-transaction 和 --quick 用在 InnoDB 大表上，能减少表锁影响并读取同一事务快照；它不能让 MyISAM、MEMORY 或导出期间发生结构变更的表自动获得同样的一致性。

--single-transaction 到底建立了哪一种快照

执行导出时，可以把主链路看成 mysqldump 发出 START TRANSACTION，会话使用 REPEATABLE READ，随后由 InnoDB 根据一致性读视图读取表数据，形成本文所说的 InnoDB snapshot。图中这条链路对应的是“读取同一快照”，不是把写入请求排队。

mysqldump \
  --single-transaction \
  --quick \
  --routines --events \
  shop > shop-$(date +%F).sql

这里的 --quick 是传输方式的选择：mysqldump 逐行读取并写出结果，适合大表。它不会改变快照语义，也不会替代校验。真正决定一致性边界的是 START TRANSACTION 和 InnoDB 的一致性读。

为什么说它“不锁表”仍然不等于没有风险

对 InnoDB 来说，--single-transaction 的价值是避免常规表锁对业务读写造成阻塞。但这并不意味着导出期间什么都可以改。官方文档特别提醒，ALTER TABLE、CREATE TABLE、DROP TABLE、RENAME TABLE 和 TRUNCATE TABLE 可能让一致性读得到错误内容或失败。

另外，MyISAM 和 MEMORY 没有 InnoDB 那样的事务快照。一个库里如果同时存在 InnoDB、MyISAM 和 MEMORY，导出的文件不能简单地宣称“全库处于同一时刻”。这正是备份窗口需要和 DDL 变更窗口错开的原因。

一条适合大表的最小检查流程

先确认表的存储引擎，再决定命令和窗口，不要直接复制一条“万能备份命令”。

1. 用 SHOW TABLE STATUS 或查询 information_schema.TABLES，确认核心表的 ENGINE 是否为 InnoDB。
2. 为导出账号核对权限；开启 GTID 且使用相关选项时，还要按当前 MySQL 版本检查额外权限要求。
3. 导出前确认没有针对目标表的结构变更计划，并把输出文件写入有足够磁盘空间的目录。
4. 导出完成后，用目标环境执行一次结构和关键行数校验，不能只看命令返回码。

如果需要记录二进制日志坐标，可以在理解 --source-data 与当前复制方案的前提下组合使用；不要把坐标选项当成一致性快照本身。

常见问题

--single-transaction 会阻塞 InnoDB 写入吗？

它的设计目标是不通过锁表阻塞普通应用读写，但导出期间的结构变更仍可能干扰读取，因此需要避开 DDL 窗口。

为什么还要加 --quick？

大表导出时，--quick 让客户端逐行读取结果，降低内存压力；它和快照一致性解决的是两个不同问题。

MyISAM 表能不能用这个参数导出？

可以执行导出命令，但不能把 MyISAM 的结果视为和 InnoDB 一样的事务一致快照。混合引擎库要单独评估一致性要求。

把备份结论落到验收上

一份可用的逻辑备份，不只是生成了一个 .sql 文件。至少要确认核心表属于 InnoDB、导出期间没有危险 DDL、文件可以在隔离环境导入，并对关键表做数量或业务样本复核。这样才能把“命令成功”与“备份可恢复”区分开。