这次单独调查一下主从延迟的时间。这里说的主从延迟，并不是指“从库更新性能跟不上主库”， 而是“一个命令从主库更新完成到从库更新完成的延迟时间。

对于每一个连上来的从库，主库都有一个client线程与之对应。 先看主从的基本数据流 1、客户端SQL更新命令 2、主库执行 3、主库写binlog 4、主库client线程读binlog发送给从库的io线程 5、从库io线程写盘（relay-log） 6、从库sql线程读relay-log 7、执行更新。 这里有涉及到两个写盘，主库binlog和从库的relaylog（3、5）。不过不用担心不停扫描文件造成的延迟，因为读文件的线程是在同一个进程内，每次写完都会广播，所以虽然看上去是异步，实际上延迟并不大。 我们主要考察步骤2完成瞬间到7开始执行之前的延时。

实际应用中主从库机器应该是分开的，这里也讨论这种情况（同机房，不同机器） 可以想象延迟很小，因此在不同机器上输出时间还需要考虑机器之间的时间同步。设计流程如下： 1、机器A上的MySQL S设置为机器B上的MySQL M的从库 2、在A上有一个简单客户端C，向M发起一个insert操作，这个操作会被同步到S。 3、在C执行mysql_real_query返回时输出当前系统微秒时间 t1 4、在S上的引擎回调接口write_row入口处输出当前系统微秒时间 t2 则 t2- t1的值是我们需要的结果。

项目中担心多个从库连接一个主库，影响主库性能，因此还要在实验二级级联主从的延迟时间。 这种结构下，在第一级从库上增加了一次写盘转发 (sql执行更新后写本地binlog),

一级主从 50~100 us 二级主从 1.1~1.2 ms