mysqldump默认锁表是因为执行flush tables with read lock保证一致性；纯innodb库可用--single-transaction+--quick不锁表，但遇myisam则自动降级为全局锁，引擎类型决定锁行为。
mysqldump 默认会锁表，但**是否真要锁，取决于你的表引擎、备份方式和一致性要求**——不是“要不要”，而是“能不能不锁”“不锁会不会丢数据”。
为什么 mysqldump 默认锁表？
因为默认行为是执行 FLUSH TABLES WITH READ LOCK（FTWRL），靠全局读锁保证备份时所有表处于同一逻辑时间点。这在 MyISAM 表上是唯一可靠方式，但在 InnoDB 上其实有更优解。
--single-transaction 能否替代锁表？
能，但有硬性前提：
-
--single-transaction只对InnoDB表生效；只要库中存在一张MyISAM表，它就自动失效，降级回 FTWRL - 必须确保
autocommit=1，否则事务快照无法正确提交 - 备份过程中严禁任何 DDL（
ALTER TABLE、DROP TABLE等），否则隐式提交会破坏快照 - 不能和
--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 就不是最优选：
-
mysqldump是逻辑备份，恢复慢、占 CPU、易内存溢出（没加--quick时全结果集进内存） - MyISAM 表无法规避锁，只能在从库做，且需先
STOP SLAVE记录Exec_Master_Log_Pos - 生产环境高并发场景，应优先考虑
Percona XtraBackup——它通过拷贝数据文件+redo log 实现真正不锁表热备
别被“--lock-tables=false”误导：它只是跳过锁，不保证一致性，只适合测试或可容忍脏读的离线场景。
ENGINE（用 SHOW CREATE TABLE tbl），比死记参数更重要。
