MySQL备份时是否需要锁表

mysqldump默认锁表是因为执行FLUSH TABLES WITH READ LOCK保证一致性；纯InnoDB库可用--single-transaction+--quick不锁表，但遇MyISAM则自动降级为全局锁，引擎类型决定锁行为。

mysqldump 默认会锁表，但**是否真要锁，取决于你的表引擎、备份方式和一致性要求**——不是“要不要”，而是“能不能不锁”“不锁会不会丢数据”。

为什么 mysqldump 默认锁表？

因为默认行为是执行 FLUSH TABLES WITH READ LOCK（FTWRL），靠全局读锁保证备份时所有表处于同一逻辑时间点。这在 MyISAM 表上是唯一可靠方式，但在 InnoDB 上其实有更优解。

--single-transaction 能否替代锁表？

能，但有硬性前提：

1. --single-transaction 只对 InnoDB 表生效；只要库中存在一张 MyISAM 表，它就自动失效，降级回 FTWRL
2. 必须确保 autocommit=1，否则事务快照无法正确提交
3. 备份过程中严禁任何 DDL（ALTER TABLE、DROP TABLE 等），否则隐式提交会破坏快照
4. 不能和 --lock-tables 或 --lock-all-tables 共用，否则报错

典型安全命令：mysqldump --single-transaction --routines --triggers -u root -p mydb > backup.sql

系统库（mysql）备份为何总卡住？

直接跑 mysqldump mysql 会卡死或报 ERROR 1142，因为权限表不支持常规 LOCK TABLES。必须加 --skip-lock-tables，且不能用 --single-transaction（对系统库无效）。

正确写法：mysqldump --skip-lock-tables -u root -p mysql user db host > mysql_privileges.sql

注意：必须有 SELECT 权限在 mysql.* 上，推荐用 root 或专用账号。

大表或混合引擎怎么办？

如果表超过 100GB，或包含 MyISAM + InnoDB 混合引擎，mysqldump 就不是最优选：

1. mysqldump 是逻辑备份，恢复慢、占 CPU、易内存溢出（没加 --quick 时全结果集进内存）
2. MyISAM 表无法规避锁，只能在从库做，且需先 STOP SLAVE 记录 Exec_Master_Log_Pos
3. 生产环境高并发场景，应优先考虑 Percona XtraBackup ——它通过拷贝数据文件+redo log 实现真正不锁表热备

别被“--lock-tables=false”误导：它只是跳过锁，不保证一致性，只适合测试或可容忍脏读的离线场景。

实际操作中最容易被忽略的点是：**引擎类型决定锁行为，而不是备份命令本身**。查清楚每张表的 ENGINE（用 SHOW CREATE TABLE tbl），比死记参数更重要。