mysqldump 默认锁表是因为需用 flush tables with read lock 保证备份一致性，尤其在非事务引擎（如 myisam）下必须依赖全局只读锁；对 innodb 则可用 --single-transaction 基于 mvcc 快照避免锁表，但要求全库为 innodb 且备份中禁止 ddl。
对 InnoDB 表，优先用 --single-transaction；MyISAM 或混合引擎库必须用 FLUSH TABLES WITH READ LOCK，但得在从库做，且不能跳过 binlog 位点同步。
为什么 mysqldump 默认会锁表？
默认行为是执行 FLUSH TABLES WITH READ LOCK（简称 FTWRL），它会让整个实例进入只读状态——所有写入、DDL、甚至事务提交都会被阻塞。这不是 mysqldump “设计成这样”，而是它为保证备份逻辑一致性所依赖的兜底机制：当引擎不支持事务快照时，只能靠全局锁冻结数据。
常见错误现象包括：
- 主库备份期间业务写请求全部 hang 住，超时失败
- 从库备份后出现明显主从延迟，
Seconds_Behind_Master持续飙升 - 备份文件里部分表结构是旧的，部分数据是新的，恢复时报错“列不存在”或“数据截断”
如何用 --single-transaction 避免锁表？
该参数仅对 InnoDB 有效，原理是在备份开始前启动一个 REPEATABLE READ 事务，利用 MVCC 快照读取数据。业务写操作完全不受影响，备份看到的是事务启动时刻的一致性视图。
实操要点：
- 必须确保库中所有表都是 InnoDB 引擎，
SHOW CREATE TABLE tbl查ENGINE=InnoDB - 不能在备份过程中执行 DDL（如
ALTER TABLE），否则会触发隐式提交，破坏快照一致性 - 如果备份耗时很长，长事务可能拖慢 purge 线程，导致
innodb_undo_log_truncate失效、undo 表空间膨胀 - 命令示例：
mysqldump --single-transaction --routines --triggers -u root -p mydb > backup.sql
混合引擎或 MyISAM 表怎么办？
只要存在一张 MyISAM 表，--single-transaction 就会失效，mysqldump 自动降级回 FTWRL。此时无法避免锁表，但可以控制风险范围：
- 务必在从库执行备份，避免主库业务中断
- 备份前先
STOP SLAVE，记录SHOW SLAVE STATUS\G中的Exec_Master_Log_Pos和Relay_Master_Log_File - 执行 FTWRL → 备份 →
UNLOCK TABLES→START SLAVE，再用记录的位点确认从库已追平 - 禁止使用
--lock-tables=false：它跳过锁逻辑，但备份结果大概率跨事务不一致，恢复后数据错乱
容易被忽略的元数据锁（MDL）问题
即使用了 --single-transaction，如果备份中途有其他连接执行了 ALTER TABLE 或 DROP TABLE，会持有 MDL 写锁，阻塞 mysqldump 的后续表访问，导致备份卡住或超时。这不是表锁，但效果一样——进程 hang 在那里。
预防方法只有两个：
- 备份窗口内禁止任何 DDL 操作（CI/CD 自动化脚本也要避开）
- 监控
SELECT * FROM performance_schema.metadata_locks，发现长时间未释放的 MDL 写锁及时干预
真正麻烦的不是锁本身，而是它和 DDL、复制位点、引擎兼容性缠在一起——单点改配置解决不了，得看全链路。
