SQL线程卡在Waiting for table metadata lock是MDL锁冲突导致的无负载型延迟，根本原因是备份脚本、DDL或慢查询长期持有元数据锁，需通过performance_schema.metadata_locks定位LOCK_STATUS='PENDING'的持锁会话，临时KILL释放，预防措施包括从库禁用FLUSH TABLES及备份加--single-transaction。
SQL线程卡在Waiting for table metadata lock
这是最隐蔽也最常见的“无负载型延迟”：从库Seconds_Behind_Master持续上涨，但CPU、IO几乎没压力，SHOW PROCESSLIST里SQL线程状态固定为Waiting for table metadata lock。
根本原因是MDL锁冲突——比如备份脚本执行了FLUSH TABLES WITH READ LOCK，或DBA手动执行了ALTER TABLE，又或慢查询长时间持有表级MDL，导致SQL线程无法获取目标表的元数据锁。
- 确认方式：查
performance_schema.metadata_locks，过滤LOCK_STATUS = 'PENDING'且OWNER_THREAD_ID对应SQL线程ID - 临时解法：用
KILL干掉持有锁的会话，但必须先查清来源（常见是未退出的mysqldump或凌晨备份） - 预防重点：从库禁止任何
FLUSH TABLES类操作；备份必须加--single-transaction --skip-lock-tables
UPDATE/DELETE语句在无主键表上全表扫描
当binlog_format = ROW且目标表没有主键或唯一索引时，从库回放UPDATE或DELETE事件无法定位具体行，只能逐行比对——100万行更新=100万次全表扫描，性能断崖式下跌。
现象是延迟突增，SHOW ENGINE INNODB STATUS里能看到大量lock_wait，且都集中在同一张表；Relay_Log_Space会快速膨胀。
- 快速验证：
SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.TABLES WHERE ... AND TABLE_NAME NOT IN (SELECT TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE CONSTRAINT_NAME IN ('PRIMARY', 'UNIQUE')); - 修复优先级：补主键（哪怕加
id BIGINT AUTO_INCREMENT PRIMARY KEY）；若不能改结构，可临时设slave_rows_search_algorithms = 'HASH_SCAN,INDEX_SCAN'（仅MySQL 5.6+有效） - 注意：
slave_rows_search_algorithms只对ROW格式生效，对STATEMENT格式无效
大事务回放期间被InnoDB行锁反复阻塞
主库一个事务更新50万行，从库SQL线程必须串行重放。但如果从库本身有其他业务写入（比如报表任务、定时JOB），这些写入可能和正在回放的事务争夺同一行的X锁，导致SQL线程不断重试、卡顿。
这不是“从库慢”，而是“从库被自己人堵住”。现象是SHOW PROCESSLIST里SQL线程状态长期为Updating或Deleting，innodb_row_lock_waits指标飙升。
- 排查路径：用
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY trx_started DESC LIMIT 5看谁在抢锁 - 关键动作：从库必须隔离——禁止任何非复制用途的写入；所有报表、ETL任务应读取只读副本（而非同步从库）
- 补充检查：
SHOW ENGINE INNODB STATUS里的TRANSACTIONS段落，找lock struct(s)和waiting for this lock to be granted字段
并行复制配置失效退化为单线程
MySQL 5.7+默认开启并行复制，但若slave_parallel_type设为'DATABASE'而业务跨库写入频繁，或slave_parallel_workers设为0，就会实际退化成单线程回放——主库16核并发写，从库1个SQL线程硬扛。
典型表现是Exec_Master_Log_Pos缓慢推进，Read_Master_Log_Pos早已追平，但Seconds_Behind_Master稳定增长。
- 检查命令：
SHOW VARIABLES LIKE 'slave_parallel%';确认slave_parallel_type为'LOGICAL_CLOCK'，且slave_parallel_workers > 0 - 生效方式（需重启复制）：
STOP SLAVE; SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; SET GLOBAL slave_parallel_workers = 8; START SLAVE; - 注意：并行复制依赖
binlog_group_commit_sync_delay等主库参数配合，若主库binlog_format不是ROW，逻辑时钟机制可能失效
真实环境里，SQL线程慢很少是单一原因。最常出现的是「无主键表 + 大事务 + MDL锁」三者叠加——一张没主键的大表被批量更新，同时从库正跑着备份，SQL线程就彻底卡死。排查时别盯着一个点猛挖，先用SHOW SLAVE STATUS\G锁定卡在哪一环，再针对性切片验证。
