mysqldump会锁表是因为默认触发flush tables with read lock（ftwrl），需获取一致性快照；加--single-transaction可对纯innodb库实现无锁备份，但遇myisam表、长事务或冲突参数即降级为锁表。
纯 InnoDB 库加 --single-transaction 就能基本不锁表；但只要存在哪怕一张 MyISAM 表，或备份时有长事务、DDL 操作，锁表风险立刻回归。
为什么 mysqldump 会锁表？关键看引擎和参数组合
mysqldump 默认行为不是“一定锁全库”，而是根据实际条件动态降级：遇到 MyISAM 表、未启用 --single-transaction、或显式加了 --lock-all-tables，就会触发 FLUSH TABLES WITH READ LOCK（FTWRL），阻塞所有写入。
真正危险的是“隐式降级”——比如你加了 --single-transaction，但库中有一张 mysql.general_log（MyISAM 引擎），mysqldump 会自动忽略该参数，退回到 FTWRL 模式。
- 查清引擎分布：
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db' AND engine != 'InnoDB'; -
--single-transaction只对 InnoDB 生效，对 MyISAM、CSV、MEMORY 表完全无效 -
--skip-lock-tables不是“无锁开关”，它只是跳过锁逻辑，但不提供一致性保障——导出的 SQL 可能跨事务不一致，恢复后数据错乱
加 --single-transaction 后还是卡住？大概率是长事务在拖后腿
即便全是 InnoDB 表，--single-transaction 也会卡在 Waiting for table flush 或 Opening tables 状态——这不是网络或磁盘问题，而是它在等一个未提交的长事务结束。
- 执行
SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED DESC LIMIT 5;，重点关注TRX_STARTED时间超过 30 秒的事务 - 这类事务通常来自未提交的报表查询、手动开启的事务、或应用层 autocommit=0 且忘记 commit
- 不要 kill 这些事务来“解救”备份——可能引发回滚风暴；应协调业务侧主动提交或回滚
- 备份窗口前 10 分钟，禁止执行
ALTER TABLE、DROP INDEX等隐式锁表操作
大表导出爆内存或超时？--quick 是刚需，不是可选项
--single-transaction 解决锁，--quick（或 -q）解决 OOM 和超时。默认模式下 mysqldump 会把整张表缓存到内存再输出，单表超 2GB 就容易触发 max_allowed_packet 错误或客户端崩溃。
- 必须加
--quick：让 mysqldump 边查边吐，逐行读取、逐行发送 - 同步调大参数：
mysqldump --max-allowed-packet=512M --quick ...（服务端也要设同样值） -
--quick对 MyISAM 表无效，所以再次强调：先确认引擎，再决定是否能用这套组合 - 若仍报 packet too large，检查客户端和服务端的
max_allowed_packet是否一致，且足够大
混合引擎或无法迁移表结构？换工具比硬扛更靠谱
当发现库中混有 MyISAM 表（如 mysql.plugin、performance_schema 中部分表）、或业务不允许停写 DDL，--single-transaction 就失效了。这时候硬调参数不如换路径。
- 优先在从库备份：
mysqldump --single-transaction --dump-slave=2 ...，避免主库压力 - 考虑
mysqlpump（MySQL 5.7+）：mysqlpump --default-parallelism=4 --single-transaction，支持多线程、按库分片，对长事务影响更小 - 真正零锁场景选物理备份：
xtrabackup --no-lock（需 MySQL 5.7+、innodb_file_per_table=ON），只在最后几秒加短暂 FTWRL 获取 binlog 位点 - 注意：
xtrabackup --no-lock不适用于含非 InnoDB 表的库；且备份后必须运行xtrabackup --prepare，否则恢复必失败
最容易被忽略的点：--single-transaction 的一致性窗口长度 = 最大单表扫描耗时，期间活跃事务会阻碍 purge 线程，导致 ibdata1 膨胀、主从延迟加剧——这不是锁表，但同样伤业务。
