--single-transaction能避免锁表，因其通过START TRANSACTION WITH CONSISTENT SNAPSHOT利用InnoDB MVCC生成快照，全程不触发FLUSH TABLES WITH READ LOCK，但仅对InnoDB有效，且需REPEATABLE READ隔离级、无长事务、不混用--lock-all-tables。
纯 InnoDB 库能基本不锁表，但必须用对参数、避开非事务表、控制长事务；一旦混入 MyISAM 或存在未提交 DDL，--single-transaction 就会失效并退化为 FTWRL。
mysqldump --single-transaction 为什么有时还是锁表？
它只对 InnoDB 表生效，原理是开启一个 REPEATABLE READ 事务快照，全程不触发 FLUSH TABLES WITH READ LOCK。但以下情况会直接退化：
- 库中存在任意一张
MyISAM、MEMORY或CSV表 → 自动 fallback 到加全局锁 - 执行 dump 时有活跃的长事务（
innodb_history_list_length持续 > 1000）→ 快照无法建立，mysqldump卡在START TRANSACTION - 手动加了
--lock-tables或--lock-all-tables→ 参数冲突，报错退出
验证是否真没锁：备份过程中执行 SHOW PROCESSLIST，看是否有线程状态为 Waiting for global read lock。
大表导出时如何避免单次操作耗时过长？
即使用了 --single-transaction，超大表（如 >50GB）的全量 SELECT 仍会拖慢主库 IO 和复制延迟。应主动分片导出：
- 按主键范围切分：
mysqldump --where="id BETWEEN 1 AND 100000" db table - 用
--skip-tz-utc --skip-comments --compact减少解析开销 - 对单表导出加
--skip-lock-tables（仅当确认该表为 InnoDB 且无外键依赖时） - 避免在导出命令里写
--all-databases，改用脚本遍历库名，逐个处理
注意：--where 不支持多表联合导出，需配合 --tables 显式指定表名。
迁移过程中的增量同步怎么不拖慢主库？
全量完成后靠 mysqlbinlog 追增量，关键在解析方式和资源控制：
- 务必使用 ROW 格式 binlog：
SELECT @@binlog_format必须返回ROW - 按时间点解析比按 position 更安全：
mysqlbinlog --start-datetime="2026-09-28 02:00:00" --stop-datetime="2026-09-28 03:00:00" mysql-bin.000001 - 加
--read-from-remote-server直连主库拉取，但要用ionice -c2 -n7降 IO 优先级 - 避免在高峰时段执行
mysqlbinlog | mysql导入，导入端也建议加--disable-log-bin关闭目标库 binlog
GTID 模式下可用 SET GLOBAL gtid_purged = 'xxx' 手动对齐，但要求源/目标都开启 gtid_mode=ON 且 enforce_gtid_consistency=ON。
真正零感知的替代方案有哪些？
如果业务完全不能容忍任何锁，且环境可控，可考虑：
- 从库备份：在从库上执行
mysqldump --single-transaction，主库全程无影响 - Percona Server 的
LOCK TABLES FOR BACKUP：不阻塞 InnoDB 写入，但需确认SHOW VARIABLES LIKE 'version%'含Percona - MySQL 8.0+ 的 CLONE PLUGIN：源库拷贝数据文件到目标，全程跳过 FTWRL，但要求版本一致、磁盘空间充足、网络带宽够
别低估 innodb_lock_wait_timeout 和 wait_timeout 的影响——它们可能让 dump 过程中途被 kill，尤其在云数据库默认值偏小的环境下。
