从库sql线程被mdl锁阻塞需人工干预：先通过show processlist和performance_schema定位持有冲突mdl读锁的慢查询、备份或未提交事务，再终止源头；大事务导致并行复制退化为串行，须拆分事务或避开高峰；read_only不防mdl争用，应启用super_read_only并禁用显式事务；半同步与并行复制共存时需关闭slave_preserve_commit_order以减少锁开销。
从库SQL线程被MDL锁阻塞怎么办
主库执行DDL后，从库SQL线程卡在Waiting for table metadata lock是典型锁争用延迟。这不是网络或IO问题，而是元数据锁（MDL）在复制回放时无法获取表级锁导致的——因为从库上可能正有长事务、慢查询或备份任务持有该表的MDL读锁。
立即排查方法：
- 在从库执行
SHOW PROCESSLIST;，找状态为Waiting for table metadata lock的线程，并记下其Id和Info（通常是ALTER TABLE ...） - 再执行
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA = 'db_name' AND OBJECT_NAME = 'table_name';，确认哪些会话（OWNER_THREAD_ID）持有了冲突锁 - 结合
SELECT * FROM performance_schema.threads WHERE THREAD_ID = xxx;定位到具体连接，看其PROCESSLIST_INFO是否是慢查询、FLUSH TABLES WITH READ LOCK或未提交事务
常见源头包括：报表SQL正在扫描大表、mysqldump 备份未结束、应用端开启事务后长时间不提交。这类问题不会随时间自动恢复，必须人工干预终止阻塞源。
大事务回放引发的串行化延迟
MySQL 5.7+ 默认启用基于逻辑时钟的并行复制（slave_parallel_type=LOGICAL_CLOCK），但遇到大事务（如单条INSERT ... SELECT影响百万行）时，整个事务会被视为一个“不可分割单元”，强制退化为单线程回放——后续所有小事务都得排队等它完成，Seconds_Behind_Master 会持续上涨。
判断依据：
-
SHOW SLAVE STATUS\G中Seconds_Behind_Master稳定增长，但Slave_SQL_Running_State显示Reading event from the relay log或Executing event，而非卡在锁上 - 对比主库
SHOW MASTER STATUS和从库Relay_Log_File/Relay_Log_Pos，发现 relay log 已写满但 SQL 线程进度停滞 - 查
information_schema.INNODB_TRX，从库没有明显长事务，排除自身业务阻塞
这不是配置错误，而是复制协议限制。缓解方式只有两个：主库拆分大事务（比如分批 INSERT），或在业务低峰期执行 DDL/DML 批量操作。切勿依赖调高 slave_parallel_workers 来解决——它对单一大事务无效。
从库只读模式下仍被业务连接干扰
很多人以为设了 read_only=ON 就万事大吉，但read_only 不阻止 SUPER 权限用户写入，也不阻止临时表、用户变量、存储过程内部的写操作。更关键的是：某些 ORM 框架或监控探针会悄悄执行 SET autocommit=0; BEGIN; SELECT ...; COMMIT; ——这种显式事务哪怕只读，也会在 InnoDB 层申请 MDL 读锁，与 DDL 冲突。
验证方法：
- 执行
SELECT COUNT(*) FROM performance_schema.events_statements_current WHERE SQL_TEXT LIKE '%BEGIN%' OR SQL_TEXT LIKE '%START TRANSACTION%'; - 检查
SHOW VARIABLES LIKE 'read_only';和SELECT user, host FROM mysql.user WHERE Super_priv = 'Y';
真正安全的做法是：super_read_only=ON（MySQL 5.7.20+），它连 SUPER 用户的写权限也禁掉；同时在应用层关闭自动事务包装，或统一使用 autocommit=1 模式。否则，任何一次未预期的 BEGIN 都可能成为延迟导火索。
半同步 + 并行复制组合下的隐性锁开销
启用 rpl_semi_sync_master_enabled=ON 和 slave_parallel_workers>0 后，你可能会发现延迟波动变大，尤其在写高峰时。这是因为半同步要求至少一个从库返回 ACK 后主库才提交，而并行复制的多个 SQL 线程在提交时需协调全局顺序（靠 slave_preserve_commit_order=ON 实现），这引入了额外的锁等待路径——即使没 DDL，单纯高并发小事务也可能因 commit order 锁排队。
权衡建议：
- 若业务容忍短暂异步（如读写分离场景允许秒级延迟），可关掉半同步，专注优化并行复制参数
- 若必须半同步，务必设
slave_preserve_commit_order=OFF（MySQL 5.7+），并接受部分事务在从库提交顺序与主库不一致——这对绝大多数业务无影响，但能显著降低锁争用 - 避免同时开启
sync_binlog=1和innodb_flush_log_at_trx_commit=1：它们会让主库每次提交都刷盘，放大半同步等待时间
锁争用延迟最麻烦的地方在于：它不报错、不中断复制，只是让 Seconds_Behind_Master 缓慢爬升，且现象高度依赖业务流量模式。监控不能只盯这个数字，得配合 performance_schema 实时抓取锁等待链，否则永远在被动救火。
