一、问题描述
遇到一个这样的问题
- 隐式大事务：update db_alart_1.sbtest1 set k=k+'11dcs1' where id between 10000 and 1001000; 延迟从20分钟开始
- 显示大事务：begin;update db_alart_1.sbtest1 set k=k+'11dcs1' where id between 10000 and 1001000; commit； 大部分延迟一会从0开始
二、问题分析
我们以前说过MTS的延迟计算有如下公式
- 从库服务器时间 - 检查点XID_EVENT header中timestamp的时间 - 主从服务器时间差
这个代码流程获取流程如下：
一、工作线程执行到事务XID_EVENT的时候，会设置如下值：
ptr_group->ts= common_header->when.tv_sec + (time_t) exec_time;
//Seconds_behind_master related //checkpoint的时候会将这个值再次传递
//mts_checkpoint_routine()
二、当进行检查点的时候设置变量ts，调用函数mts_checkpoint_routine
/*
Update the rli->last_master_timestamp for reporting correct Seconds_behind_master.
If GAQ is empty, set it to zero.
Else, update it with the timestamp of the first job of the Slave_job_queue
which was assigned in the Log_event::get_slave_worker() function.
*/
ts= rli->gaq->empty()
? 0
: reinterpret_cast<Slave_job_group*>(rli->gaq->head_queue())->ts;
//rli->gaq->head_queue 检查点位置的GROUP的时间
三、更改last_master_timestamp值为ts变量，函数Relay_log_info::reset_notified_checkpoint
last_master_timestamp= new_ts;//设置last_master_timestamp为ts
也就是如下：
image.png
左边<---右边 GAP队列表示
x代表是已经提交的位置，o代表正在执行，检查点已经做到了LWM位置，GAP队列出队了，那么计算就是第一个o位置xid event的时间。
显然我们知道的是
- 显示事务，xid event记录的时间为commit命令发起的时间
- 隐式事务，xid event记录的时间为语句发起的时间
那么在计算延迟的时候，显示事务从0开始计数，隐式事务从主库执行时间开始计数。
因此我们得出结论：
如果长期没有新的事务那么GAP队列会出队完成，且清空。当新的事务到来 第一个GTID EVENT会分配GROUP元素，并且放入GAP队列，
gaq->assigned_group_index= gaq->en_queue(&group);
代表一个事务开始了,那么这个时候，GAP队列就不为空了。当SQL协调线程分配到XID event的时候，会将这个event的 timestap 赋予给GROUP->TS，作为计算延迟的标准。
但是这里有一个特殊情况（疑问）：
事务较大，虽然GTID EVENT分发了但是由于分发实际的数据even的t时间较长，还没来到XID event，那么这个时候GTOUP->TS 到底为何值，要看GROUP 结构的初始化是如何做的了。这个后面在分析一下。
三、测试
测试很简单：
-
显示大事务
image.png
从0开始计数。
-
隐式大事务
image.png
从主库执行时间开始计数。
仅此记录，不做过多描述。
