主库锁表最常卡在flush tables with read lock，因其需等待所有活跃事务（含长事务）结束才能生效，导致写入停滞；mysqldump --single-transaction仅对innodb有效且依赖row格式binlog、无ddl、非只读模式；xtrabackup可完全规避锁表，但必须执行--apply-log恢复一致性；gtid模式下可用master_auto_position=1简化配置，前提server_id唯一且gtid_executed完整。
主库锁表发生在 FLUSH TABLES WITH READ LOCK 时
主从初始化最常卡在这一句：它会全局阻塞所有写操作，哪怕只执行几秒，对线上业务也是致命的。根本原因不是命令本身慢，而是它必须等所有活跃事务（尤其是长事务）提交或回滚后才能生效——如果此时有个未提交的 UPDATE 或 INSERT 正在跑，FLUSH TABLES WITH READ LOCK 就会一直挂起，主库写入彻底停滞。
mysqldump --single-transaction 能跳过锁表，但有前提
InnoDB 表可用该参数实现“无锁备份”，原理是利用 MVCC 快照读，不依赖全局读锁。但必须同时满足：
-
binlog_format必须为ROW（否则快照可能不一致） - 备份期间不能有
DDL操作（如ALTER TABLE），否则会触发隐式提交，破坏事务一致性 - 主库不能启用
read_only=ON或super_read_only=ON，否则mysqldump连接会被拒绝
典型安全命令：mysqldump -u root -p --single-transaction --set-gtid-purged=OFF --master-data=2 database_name > backup.sql
用 Percona XtraBackup 完全规避锁表
物理备份工具，对 InnoDB 表全程不加锁，连 DDL 都不影响。关键点：
- 主库无需停写，备份过程业务照常运行
- 备份文件自带位点信息（
xtrabackup_binlog_info），直接用于从库CHANGE MASTER TO - 必须在从库执行
--apply-log恢复一致性，不能直接cp文件过去就启动复制
常见误操作：跳过 --apply-log 直接恢复，会导致从库复制报错 Relay log read failure 或数据页损坏。
GTID 模式下可绕过位点手动计算
如果主库已开启 gtid_mode=ON，初始化时不用关心 MASTER_LOG_FILE 和 MASTER_LOG_POS，从库直接用 CHANGE MASTER TO MASTER_AUTO_POSITION = 1 即可。但注意：
- 主从
server_id必须唯一，否则复制线程启动即失败 - 备份前确认主库
gtid_executed已包含全部事务（执行SELECT @@global.gtid_executed;） - 若从库之前有旧复制关系，需先
RESET SLAVE ALL清空旧 GTID 集合，否则会冲突
真正麻烦的不是技术动作，而是备份窗口期里没人敢动主库的 DDL —— 一个没通知到的 ADD COLUMN 就能让整个初始化流程回退重来。
