mysqldump加--single-transaction可不锁表备份，因其基于InnoDB MVCC启动一致性快照事务，只在dump开始时BEGIN TRANSACTION，读取均基于该时间点快照，不阻塞DML；但要求引擎为InnoDB、未开启GTID（或显式处理）、且备份期间禁止DDL。
mysqldump 加 --single-transaction 是最常用且有效的方案，但前提是主库用的是 InnoDB 引擎、未开启 GTID（或明确处理 GTID）、且备份期间不执行 DDL。
mysqldump --single-transaction 为什么能不锁表
InnoDB 支持 MVCC（多版本并发控制），--single-transaction 本质是启动一个一致性快照事务：
- 它会在 dump 开始时执行
BEGIN TRANSACTION，之后所有表读取都基于该事务时间点的快照 - 不阻塞 INSERT/UPDATE/DELETE，也不加表级读锁（区别于
--lock-all-tables） - 但要求整个过程不能有 DDL（如
ALTER TABLE、DROP TABLE），否则会触发隐式提交，破坏快照一致性
常见错误现象：
- 备份中途从库同步延迟突增 → 主库 dump 过程中混入了 DDL
- 恢复后从库报错
Could not execute Write_rows event on table ... Error_code: 1032→ 快照不一致或 binlog position 记录错位
使用场景限制：
- 仅对 InnoDB 表生效；MyISAM 表仍会被锁（需额外加
--lock-tables=false并接受风险） - 不适用于开启了 GTID 的集群，除非显式加
--set-gtid-purged=off（否则 dump 文件里会写死 GTID 集合，导入时冲突）
--master-data=2 和 binlog position 的准确性陷阱
--master-data=2 会把 SHOW MASTER STATUS 结果以注释形式写进 dump 文件，例如：
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=456789;
但它不是在 dump 开始时立即获取 position，而是在 FLUSH TABLES WITH READ LOCK 后立刻执行 SHOW MASTER STATUS，然后马上 UNLOCK TABLES —— 这个锁只持续毫秒级，只为冻结 binlog 坐标。
容易踩的坑：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 如果主库在
FLUSH TABLES WITH READ LOCK前刚刷了一次 binlog（比如max_binlog_size触发轮转），SHOW MASTER STATUS返回的File可能已是新文件，但 dump 内容仍来自旧文件快照 → 从库CHANGE MASTER TO后找不到起始事件 - 解决办法：确保
max_binlog_size足够大（如 500M），或用Percona XtraBackup替代，它通过xtrabackup_binlog_info文件记录更可靠的坐标
用 Percona XtraBackup 实现真正无锁热备
mysqldump 是逻辑备份，恢复慢、无法增量、不兼容大库；Percona XtraBackup 是物理备份，支持热备 + 增量 + 流式压缩，且不依赖事务隔离级别。
关键命令示例：
innobackupex --user=backupuser --password=123456 --slave-info --no-timestamp /backup/full/
参数说明：
-
--slave-info：自动记录主库 binlog 文件和 position 到xtrabackup_slave_info，比mysqldump的注释更可靠 -
--no-timestamp：避免生成时间戳子目录，方便脚本管理 - 要求主库已启用
log-bin且未设置skip-log-bin或binlog-ignore-db（否则从库无法定位起点）
性能影响：
- 备份过程会持续读磁盘，IO 利用率飙升，建议避开业务高峰
- 不锁表，但会短暂加全局 log mutex（微秒级），不影响业务 SQL 执行
真正“不锁表”的边界很窄：
-
mysqldump --single-transaction对 DML 安全，但对 DDL 敏感； -
Percona XtraBackup物理层无锁，但要求 binlog 开启且配置干净； - 任何方案都无法绕过
FLUSH TABLES WITH READ LOCK的毫秒级协调锁（用于获取精确 position），只是它足够短，业务几乎无感。
别迷信“完全无锁”，重点是确认你的引擎、GTID 状态、binlog 配置是否匹配所选工具的前提条件。
