--single-transaction 卡住是因为其默认隐式执行 flush tables with read lock，导致从库 sql 线程因等待全局元数据锁（mdl）而阻塞在 system lock 状态，进而使 seconds_behind_master 持续上涨。
mysqldump --single-transaction 为什么卡住 SQL 线程
因为 --single-transaction 默认会执行 FLUSH TABLES WITH READ LOCK（除非明确加 --skip-lock-tables），这个全局读锁会阻塞 Slave_SQL_Running 线程——它需要获取 metadata lock 来执行 DDL 或修改表结构，但锁被 dump 进程占着。
常见现象是：SHOW SLAVE STATUS\G 中 Slave_SQL_Running_State 显示 System lock，Seconds_Behind_Master 持续上涨，而 Last_SQL_Error 为空。
- 只在从库执行备份时才容易暴露：主库没 SQL 线程，不受影响；但从库一边要回放 relay log，一边被 dump 锁住，就直接卡死
-
--single-transaction本身依赖事务一致性，但它仍需先获取一次全局 MDL 锁来“快照”当前表结构——这一步就是冲突点 - 即使你用的是 GTID 模式、启用了并行复制，只要 dump 进程持有
FLUSH TABLES WITH READ LOCK，SQL 线程（或任何 Worker Thread）都会等在System lock
如何确认是 mysqldump 引起的锁冲突
别只看进程列表。重点查三处：
- 执行
SHOW PROCESSLIST，找状态为Waiting for global read lock或Waiting for table flush的线程，其Info字段常含FLUSH TABLES - 查
performance_schema.metadata_locks（MySQL 5.7+）：SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_TYPE = 'GLOBAL' AND LOCK_STATUS = 'PENDING';
如果返回非空，说明有线程在等全局锁 - 对比时间点：错误日志里
System lock开始出现的时间，是否紧挨着 mysqldump 启动时间？
备份时不中断同步的实操建议
核心原则：避免任何需要全局读锁的操作。
- 从库备份优先用
--dump-slave=2（MySQL 5.6+），它不加全局锁，而是从SHOW SLAVE STATUS读取主库位点，适合 GTID 和非 GTID 场景 - 绝对不要在从库跑
mysqldump --master-data=2—— 它强制FLUSH TABLES WITH READ LOCK，且只适用于主库导出 - 如果必须用
--single-transaction，务必加--skip-lock-tables，但要注意：某些 DDL（如RENAME TABLE）在此期间执行会导致 dump 不一致 - 备份窗口内禁止在从库执行 DDL；如果业务允许，临时关掉
slave_parallel_workers，减少锁竞争面
已经卡住了，怎么快速恢复
不是 kill mysqldump 就完事——它可能已拿到锁但还没释放。得主动干预锁生命周期：
- 先查谁拿了锁：
SELECT THREAD_ID, PROCESSLIST_INFO FROM performance_schema.threads WHERE PROCESSLIST_INFO LIKE '%FLUSH TABLES%';
- 用
KILL干掉对应THREAD_ID（不是 PID） - 再立刻检查
SHOW SLAVE STATUS\G：如果Slave_SQL_Running_State变成Reading event from the relay log，说明锁释放成功，同步会自动追上 - 若仍卡在
System lock，可能是其他长事务（如未提交的SELECT ... FOR UPDATE）也占着 MDL，需一并清理
真正麻烦的不是锁本身，而是锁住期间 relay log 积压——一旦积压太多，SQL 线程重启后要顺序重放，延迟可能长达数小时。所以备份策略必须和复制链路耦合设计，不能当成孤立操作。
