MySQL主从延迟飙升？元数据锁可能是“真凶”

现象：IO线程欢快，SQL线程却在划水

看到从库的SecondsBehindMaster从30秒直线飙升到1000秒，你是不是冷汗直冒？
IO线程还在欢快地读取日志，SQL线程却像被冻住了一样，一步一步往后挪，而且越来越慢。
这真的不是网络问题，而是你的DDL操作在暗地里搞破坏。

我见过太多线上事故的根源就藏在一条看似不起眼的ALTERTABLE里——有个哥们改了一个varchar(5000)字段，想扩容到varchar(6000)，结果整个从库崩溃了。
今天就给你讲清楚这个坑到底怎么踩，以及怎么安稳地跨过去。

问题最初看起来很诡异。你用SHOWREPLICASTATUS一看，SecondsBehindMaster直接冲到1000+秒，业务告诉你数据没同步，但是你登上从库查看：

SecondsBehindMaster:1000
IOThreadRunning:Yes
SQLThreadRunning:Yes
RelayLogIORunning:Yes

这说明读日志的线程活得好好的，问题一定出在应用日志的线程上。
IO线程正常工作，说明主库没问题，网络也没问题。
那为什么SQL线程这么慢呢？多半是被什么东西卡住了。

定位：SHOWREPLICASTATUS里的假象

这里最轻易出现的差错就是看错位置。你或许会看到

SQLDelay:0
RelayLogPos:1024

看起来SQLDelay是0，说明没有故意延迟复制，RelayLogPos也在那儿……可这TM一个小时都没动过！
这就是关键信号：中继日志位置不再增长，说明SQL线程卡住了。
这时候，很多人会傻愣愣地查看网络、检查磁盘空间、观察缓冲池，完全没察觉到，问题就在这时出现了：某张表已经被锁定，SQL线程正在依次排队等着解锁