--- 注意：本文是《深入理解MySQL主从原理 32节》的第28节 订阅参考： https://www.herecours.com/d/file/efpub/2026/01-01/20260301121849750310](https://upload-images.jianshu.io/upload_images/7398834-fb074567e6620f57.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240) ###二、相关测试 因为上面的延迟情形很多我们都已经测试和讲述过了。下面我们测试锁造成的延迟情形。 #####（1）Innodb层的行锁造成的延迟 这个很容测试，我只要先在从库做一个事务和SQL线程修改的数据相同即可以出现，大概测试如下： ``` 从库： mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> delete from tmpk; Query OK, 4 rows affected (0.00 sec) 不要提交 主库执行同样的语句 mysql> delete from tmpk; Query OK, 4 rows affected (0.30 sec) ``` 这个时候你会观察到延迟如下：  如果查看sys.innodb\_lock\_waits能看到如下的结果：  当然如果查看INNODB\_TRX也可以观察到事务的存在，这里就不截图了，大家可以自己试试。 ######（2）MySQL层的MDL LOCK造成的延迟 这种情况也非常容易测试，我们只需要开启一个事务做一个select，然后主库对同样的表做DDL就可以出现如下： ``` 从库： mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> mysql> mysql> select * from tkkk limit 1; +------+------+------+ | a | b | c | +------+------+------+ | 3 | 3 | 100 | +------+------+------+ 1 row in set (0.00 sec) 不要提交，表上MDL LOCK就不会释放 主库执行语句： mysql> alter table tmpk add testc int ; Query OK, 0 rows affected (1.14 sec) Records: 0 Duplicates: 0 Warnings: 0 ``` 这个时候你将会看到如下的信息：  我们可以通过state看到这是等待MDL lock获取而导致的延迟，关于MDL lock的详情可以参考我的文章： http://blog.itpub.net/7728585/viewspace-2143093/ ###三、总结 通过整个系列，我们应该清楚了Seconds\_Behind\_Master计算的方法，同时如果出现了延迟，我们首先查看从库是否有负载，根据是否有负载进行区别对待，注意这里的负载一定要使用**top -H**查看io/sql/woker线程的负载。我曾不止一次的遇到朋友问我延迟问题，当我问他负载如何的时候他告诉我负载不高啊整体负载也就不到2，这里我们应该注意的是对于一个线程只能使用到一个CPU核，虽然整体负载不到2但是可能io/sql/worker线程已经跑满了，实际上负载已经很高了，我们来看下面的这个截图就是sql线程负载高的截图如下：  这个截图我们发现虽然整体负载不高在1多一点，但是Lwp号20092的线程已经跑满了，这个线程就是我们的sql线程，这个时候出现延迟是很可能的，这个截图正是来自一个没有合理使用主键或者唯一键造成的延迟的案例，案例如下： https://www.jianshu.com/p/56e8ca2223a0 我们查看CPU负载应该使用**top -H**去查看，查看io负载可以使用iotop，iostat等工具。我需要强调一下看MySQL负载的时候我们必须用**线程**的眼光去看，第29节将让你获得这种能力。 到这里整个系列接近尾声，大家会发现主从的原理的还是比较复杂的，这可能颠覆了以前我们的认知，以前我们认为主从无非就是搭建起来能跑同时知道有io/sql线程就可以了（这确实很简单）。整个系列结论很简单，我们无非就是想配置出安全高效的从库同时知道延迟是怎么导致的，出现延迟后我们如何处理，我自认为本系列还是将这些问题讲解得很清楚了。当然如果本系列的原理部分都能够理解得很好，那么工作中解决主从问题一定会更加得心应手。 --- 第28节结束