从库sql线程被mdl锁卡住是“无负载型延迟”主因，表现为seconds_behind_master上涨但cpu/io不高，状态为waiting for table metadata lock；需查performance_schema.metadata_locks定位pending锁并kill冲突会话。
从库 SQL 线程被 MDL 锁卡住：show slave status 显示延迟但 CPU/IO 并不高
这是典型的“无负载型延迟”——从库没在忙执行，却迟迟不推进。根本原因常是 MySQL 层的元数据锁（MDL）冲突：SQL 线程正试图执行一个 ALTER TABLE 或 DROP INDEX，但此时从库上另有连接（比如备份脚本、DBA 手动 FLUSH TABLES WITH READ LOCK、甚至慢查询持有表级锁）占着 MDL，导致 SQL 线程无限等待。
- 现象：
Seconds_Behind_Master持续上涨，但SHOW PROCESSLIST里 SQL 线程状态长期卡在Waiting for table metadata lock - 确认方法：在从库执行
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA NOT IN ('performance_schema', 'mysql');，看是否有LOCK_STATUS = 'PENDING'且OWNER_THREAD_ID对应 SQL 线程 ID - 临时解法：杀掉持有锁的会话（
KILL <thread_id></thread_id>），但需先查清来源——常见是未结束的mysqldump或凌晨自动备份任务 - 预防要点：从库禁止手动加全局读锁；备份务必用
--single-transaction（InnoDB 表）+--skip-lock-tables，避免触发FLUSH TABLES
UPDATE/DELETE 无主键表引发行级锁放大：Row 格式下的隐式全表扫描
当 binlog_format = ROW 且目标表缺失主键或唯一索引时，MySQL 从库回放 UPDATE 或 DELETE 事件无法准确定位行，只能退化为全表扫描 + 行比对，极易和正在运行的其他写入事务发生行锁冲突，让 SQL 线程反复重试、卡顿。
- 现象：延迟突增，
SHOW ENGINE INNODB STATUS中可见大量lock_wait记录，且锁等待对象集中在同一张无主键表 - 验证命令：
SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql','sys','information_schema','performance_schema') AND TABLE_NAME NOT IN (SELECT TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE CONSTRAINT_NAME='PRIMARY' OR CONSTRAINT_NAME='UNIQUE'); - 修复路径：给表补上主键（哪怕加个自增
id）；若暂时不能改表结构，可临时调大slave_rows_search_algorithms（如设为HASH_SCAN,INDEX_SCAN），但只是缓解，不治本 - 注意：
slave_rows_search_algorithms在 MySQL 5.6+ 才生效，且仅影响基于行的复制，对语句格式无效
大事务回放期间被 InnoDB 行锁阻塞：从库也有“业务写入”？
很多人默认从库只读，但实际中常有监控采集、ETL 写入、或者应用误连从库写数据。一旦这些写入和 SQL 线程要更新同一行，就会触发 InnoDB 行锁等待——SQL 线程不是“特权线程”，它也要排队等锁。
- 典型场景：应用配置错误，把部分写请求发到从库；或 DBA 在从库跑清洗脚本，更新了和主库同步中的表
- 排查线索：
SHOW PROCESSLIST中 SQL 线程状态为Updating或Locked，同时INFORMATION_SCHEMA.INNODB_TRX里能看到两个活跃事务，TRX_MYSQL_THREAD_ID分别对应 SQL 线程和业务线程，且TRX_WAITING_LOCK_ID互指 - 关键检查项：
SELECT @@read_only;必须为ON；若为OFF，立刻设为ON（SET GLOBAL read_only = ON;），并审计所有连接来源 - 补充提醒：
read_only不影响 super 权限用户，所以还要确认账号权限是否过度开放
DDL 执行时的隐式锁升级：为什么 ALTER 一跑，延迟就跳几十秒？
ALTER TABLE 在主库执行完才写入 binlog，而从库 SQL 线程必须串行执行它。问题在于：DDL 本身会申请强 MDL（MDL_EXCLUSIVE），期间所有对该表的读写请求都会被阻塞——包括后续其他事务中对该表的任何操作，哪怕那些事务本身很小。
- 现象：延迟值不是缓慢爬升，而是突然跳变（比如从 0 直接跳到 42），且持续时间 ≈ 主库 DDL 执行时间 × 2（因 Row 格式下 timestamp 计算方式）
- 对比验证：主库执行
ALTER TABLE t1 ADD COLUMN c1 INT;前后，用SELECT UNIX_TIMESTAMP() - last_master_timestamp FROM mysql.slave_relay_log_info;观察跳变点 - 安全做法：优先用
ALGORITHM=INSTANT（8.0.12+）或ALGORITHM=INPLACE；避免COPY算法；DDL 务必在业务低峰期执行，并提前检查从库负载 - 容易忽略的坑：
pt-online-schema-change虽能规避锁表，但它本身会产生大量小事务，在从库仍可能因单线程瓶颈堆积延迟，需配合多线程复制使用
锁引起的延迟最难定位，因为它不体现为资源耗尽，而是一种“静默等待”。真正要盯住的不是 Seconds_Behind_Master 数值本身，而是它的变化节奏——突增、阶梯式上涨、长时间平台期，每种形态背后对应的锁类型都不同。
