mysqldump锁表根本原因是参数误用、引擎混用及场景未隔离；纯innodb库应使用--single-transaction+--quick规避ftwrl，禁用--lock-tables，且须确认无myisam表，--lock-tables=false不保障一致性，严禁用于生产备份。
mysqldump 备份时出现“锁表”甚至引发死锁，根本原因不是备份工具本身出错，而是参数误用 + 存储引擎混用 + 未隔离备份场景导致的连锁反应。纯 InnoDB 库完全可做到无锁备份；一旦出现死锁，说明已触发 FLUSH TABLES WITH READ LOCK（FTWRL），且与主从复制、长事务或 MyISAM 表形成资源争抢。
确认是否真被 FLUSH TABLES WITH READ LOCK 卡住
别急着 kill 进程，先快速判断锁源：
执行 SHOW PROCESSLIST;，重点看 State 列为 Locked 或 Waiting for table flush 的线程，再比对 Info 是否含 FLUSH TABLES WITH READ LOCK。
若发现该语句正被某个 mysqldump 进程执行，且业务写入明显阻塞，说明已进入全局读锁状态。
此时不要 kill 正在执行 UPDATE/INSERT 的业务线程——它可能正持有行锁，kill 后会触发回滚风暴，加剧锁等待。
纯 InnoDB 库必须用 --single-transaction + --quick
--single-transaction 是唯一能绕过 FTWRL 的安全方案，但它只对 InnoDB 表生效：
• 必须搭配 --quick（或 -q），否则大表导出会缓存整张表到内存，触发 max_allowed_packet 错误或 OOM
• 绝对不能和 --lock-tables 共用，后者默认开启，会直接覆盖前者效果
• 若库中存在任意一张 MyISAM 表，mysqldump 会自动退回到 FTWRL 模式——先运行：SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db'; 确认引擎分布
别碰 --lock-tables=false，它不解决一致性问题
这个参数只是跳过锁逻辑，不提供任何事务一致性保障：
• 备份过程中若发生跨表 DML（如 A 表更新后 B 表才更新），导出的 SQL 可能 A 是旧版、B 是新版，恢复后数据逻辑断裂
• 它不是轻量版 --single-transaction，压根没有 MVCC 快照机制
• 仅适用于测试库或允许脏读的离线归档，生产环境主库全量备份严禁使用
备份时已卡死，救急操作要分清主次
若 dump 已卡住且业务写入中断：
• 先确认该 dump 进程 ID（来自 SHOW PROCESSLIST），再执行 KILL [Id] 释放 FTWRL —— 注意：备份文件将不完整，需重跑
• 若卡在备库且用的是 Percona XtraBackup，它的 FTWRL 阶段只用于拷贝非 InnoDB 文件（如 .frm、.MYI），此时应优先检查是否有大量 MyISAM 表拖慢该阶段
• 不要试图通过调高 innodb_lock_wait_timeout 来“等它自己结束”，这只会延长业务阻塞时间
MyISAM 表留在生产库还假装它是 InnoDB；或者一边开着长事务一边跑 --single-transaction，结果快照无法建立——这些细节不查清楚，换什么工具都还会锁。
