从库SQL线程被DDL阻塞时会卡在“Waiting for table metadata lock”状态，因DDL需排他MDL锁而被从库上未提交事务或慢查询持有的读锁阻塞，导致Exec_Master_Log_Pos停滞、Relay_Log_Space持续增长，必须通过performance_schema定位并终止持锁事务。
从库SQL线程被DDL阻塞时，会卡在Waiting for table metadata lock
主库执行ALTER TABLE这类DDL语句时，会生成一个大事件写入binlog；从库SQL线程必须串行重放它。但DDL执行前需获取表级MDL（metadata lock），而此时从库上可能正有长事务、慢查询或未提交事务持有该表的MDL读锁——哪怕那些事务跟DDL完全无关，SQL线程也会一直等，状态变成Waiting for table metadata lock。
这种等待不体现在Seconds_Behind_Master里，因为SQL线程根本没开始执行，Exec_Master_Log_Pos停在DDL前的位置不动，Relay_Log_Space却持续增长。
- 查阻塞源：
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA = 'db_name' AND OBJECT_NAME = 'tbl_name'; - 确认谁在持锁：
SELECT THREAD_ID, PROCESSLIST_INFO FROM performance_schema.threads t JOIN performance_schema.events_statements_current e USING (THREAD_ID) WHERE e.STATE = 'EXECUTING'; - 杀掉无关长事务：
KILL（务必先确认不影响业务）thread_id;
大事务回放期间，DML操作触发行锁/间隙锁冲突
主库一个耗时200秒的UPDATE大事务，在从库也是单线程重放。这期间它会持续持有大量行锁或间隙锁；如果从库同时有应用直连执行了SELECT ... FOR UPDATE或INSERT，就可能因锁等待超时报Lock wait timeout exceeded。
这不是主库的问题，而是从库自身并发访问与SQL线程回放之间的资源争用——SQL线程本身成了锁持有者，且无法像主库那样并行释放。
- 典型现象：
SHOW PROCESSLIST里看到用户连接状态为Waiting for table level lock或Updating，且Time值不断增大 - 临时缓解：暂停从库上的非必要写操作，或把业务读写路由切回主库（若架构支持）
- 长期规避：拆分大事务，避免单条DML影响超5万行；启用
slave_parallel_workers > 0缓解单表瓶颈（但跨表事务仍无效）
innodb_lock_wait_timeout设置过小会放大延迟引发的锁等待失败
从库SQL线程回放慢 → 用户查询等锁时间变长 → 更容易触达innodb_lock_wait_timeout阈值（默认50秒）。一旦超时，事务直接回滚，业务报错，而实际锁可能几秒后就释放了。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
这个参数对主库和从库应区别对待：主库可保持默认，但从库面对回放压力，建议调高到120甚至300秒，给锁等待留出缓冲空间。
- 查看当前值：
SELECT @@innodb_lock_wait_timeout; - 动态调整（无需重启）：
SET GLOBAL innodb_lock_wait_timeout = 120; - 注意：该变量是全局级，会影响所有新连接；已有连接仍沿用旧值
真正麻烦的是“延迟+锁等待”形成的负向循环
延迟本身不是故障，但一旦叠加锁等待，就会自我强化：SQL线程卡住 → 延迟增大 → 更多应用查询落到从库 → 更多锁竞争 → 更多等待和超时 → 进一步拖慢SQL线程。这时候光看Seconds_Behind_Master已经没意义，必须立刻拆开看Read_Master_Log_Pos和Exec_Master_Log_Pos的差值是否持续扩大，再结合SHOW ENGINE INNODB STATUS\G里的TRANSACTIONS部分定位活锁。
最容易被忽略的一点是：从库磁盘I/O慢（比如relay log写入延迟）会让SQL线程更频繁地等待刷盘，间接拉长锁持有时间——所以iostat -xm 1和sync_relay_log = 10000这类配置，比调优SQL本身还关键。
