ftwrl 不保证事务一致性，仅阻塞写操作而不等待事务结束；innodb 一致性备份应依赖 --single-transaction + repeatable read 快照，配合 binlog 位点记录。
FTWRL 会阻塞所有写操作，但不保证事务一致性
执行 FLUSH TABLES WITH READ LOCK 后，MySQL 确实会暂停所有 DML（INSERT/UPDATE/DELETE）和 DDL（ALTER/DROP），看起来“数据不动了”，但这只是表级锁的表象。它**不等待正在运行的事务提交或回滚**，也不阻止新事务启动——只要该事务只读，就能继续执行。这意味着：如果你在 FTWRL 期间有长事务正在更新某张表，它的修改可能尚未刷盘，而 FTWRL 又不允许你等它结束，备份拿到的就是一个“中间态”快照，不是一致点。
常见错误现象：
– 备份恢复后，InnoDB 表出现 ERROR 1032 (HY000): Can't find record in 'xxx'
– 主从切换后从库复制中断，报 Row doesn't exist in table
- FTWRL 是全局锁，作用于整个实例，影响面大，运维窗口难协调
- 它对 MyISAM 表有效（因为无事务），但对 InnoDB 仅能配合
mysqldump --single-transaction才可能安全——而两者不能混用 - 若备份工具未显式释放锁（如脚本异常退出），锁会一直持有，导致业务写入长时间卡住
真正保证一致性得靠 --single-transaction + 事务隔离级别
InnoDB 的一致性备份核心不是锁表，而是利用 MVCC 和事务快照。启用 mysqldump --single-transaction 时，dump 进程会先开启一个 REPEATABLE READ 事务，再执行 SELECT。这个事务从开始时刻就建立了一个全局一致的快照（通过 read view），后续所有查询都基于该快照，不受其他并发事务提交的影响。
关键前提是：
– 表必须是 InnoDB 引擎（MyISAM 不支持事务，强制退化为 FTWRL）
– dump 过程中不能有长事务持续运行（否则 read view 无法清理 undo log，可能导致备份变慢甚至失败）
- 务必确认 MySQL 配置项
innodb_file_per_table = ON，否则单表恢复困难 - 避免在备份期间执行
ALTER TABLE或OPTIMIZE TABLE，它们会隐式提交当前事务，破坏快照一致性 - 如果备份包含非事务表（如 CSV、MEMORY），需额外用 FTWRL 单独处理，但要控制其时间极短
FTWRL vs 事务锁：本质不同，不能互相替代
FLUSH TABLES WITH READ LOCK 是 server 层的全局状态锁，由主线程管理，直接挂起所有更新线程；而事务锁（如行锁、间隙锁）是 InnoDB 存储引擎层的并发控制机制，只对本事务可见，且受隔离级别约束。两者生命周期、作用域、释放时机完全不同。
典型混淆场景：
– 以为加了 FTWRL 就不用管事务，结果备份时另一个连接还在跑 BEGIN; UPDATE ...; （未提交），dump 读到的是旧值，但该事务后续提交后，binlog 里就有新值，主从数据就错位了
– 用 SELECT ... FOR UPDATE 锁住几行，误以为这能保护整库备份一致性——其实它只锁住当前事务看到的那几行，对其他事务的写入无约束力
- FTWRL 锁住的是“物理表结构和缓存”，事务锁锁住的是“逻辑数据版本”
- FTWRL 在
UNLOCK TABLES或客户端断开后才释放；事务锁在事务COMMIT或ROLLBACK后立即释放 - 监控 FTWRL 是否生效：查
SHOW PROCESSLIST中状态为Waiting for global read lock的线程；查事务锁：用SELECT * FROM information_schema.INNODB_TRX
生产环境推荐组合：--single-transaction + binlog position + 可选轻量 FTWRL
最常用也最稳妥的一致性备份路径是：先用 mysqldump --single-transaction --master-data=2 导出数据，它会在 dump 文件开头自动记录 CHANGE MASTER TO 所需的 binlog 文件名与位置（即一致性位点）。如果备份中包含非事务表，可在 dump 前加一段极短的 FTWRL（毫秒级），仅用于刷新并锁定这些表，立刻 unlock，再启动 dump。
容易被忽略的关键点：
– --master-data=2 记录的是执行 SHOW MASTER STATUS 的时刻，不是 dump 开始时刻；而 --single-transaction 的一致性快照是事务 START 的时刻——这两个时间点接近但不严格相等，不过对大多数场景可接受
– 若启用了 GTID，应改用 --set-gtid-purged=ON，否则恢复时可能因 GTID 冲突失败
- 不要依赖
mysqldump --lock-all-tables，它本质就是 FTWRL，问题同上 - Percona XtraBackup 虽底层也用
backup_lock（5.7+）或 FTWRL（5.6），但它在拷贝文件前会自动获取并记录精确的 binlog 位点，比手动组合更可靠 - 备份后务必验证：用
mysqlcheck --check校验表结构，用diff比对小样本数据，而不是只看 dump 文件大小
