共计 837 个字符，预计需要花费 3 分钟才能阅读完成。
问题
一段 binlog 如上图，为什么这个 BEGIN 执行了 5 秒，是数据库卡了还是统计错了？
试验
先宽油做一个数据库：
为了试验不便，咱们改一下 mysql 的提示符，将命令行的以后工夫显示在下面，
将 binlog 格局改为 statement：
创立一个试验表：
跑一个事务：
解开对应的 binlog：
失去后果：
咱们看到三组工夫：
1. 黄色局部：每个 binlog event 前都会带有一个工夫戳，这个工夫戳和咱们执行每个语句时的开始工夫对应（截图中会偶然偏差 1s，是因为 SQL 是手工敲的，须要一些工夫）
2. 红色局部：exec_time，每个语句的 exec_time 与语句的执行工夫对应，本例中是与 sleep 的时长对应，
而 BEGIN 语句的 exec_time 始终与第一个句子的执行工夫雷同，其起因是 BEGIN 是在第一个语句执行时，与第一个语句同时写入 binlog 的，这就引起了 exec_time 统计的偏差：BEGIN 的 exec_time 实际上是其后第一个语句的执行工夫。
3. 每个语句前会有一个 SET TIMESTAMP，咱们都晓得其会影响语句中的工夫函数，比方 now() 函数的工夫基准。
咱们重做一次试验，验证一下手工 SET TIMESTAMP 的影响：
如上图，咱们扭转了 timestamp。来看一下 binlog 的体现：
从图中能够看到：
1. binlog event 的工夫戳随着 timestamp 变动，不再示意语句的理论开始工夫，而是都置为设定的工夫。
2. exec_time 计算呈现了谬误，不再示意理论的运行工夫
由下面的试验，咱们失去如下论断：
1. exec_time 是语句的运行工夫。会受到 set timestamp 影响变得不精确
2. binlog event 的工夫戳，是语句理论的开始工夫。会受到 set timestamp 影响失去意义。
下期预报：
在慢日志，还有两个工夫量：query_time 和 lock_time。
咱们在下一期会介绍这几个量的意义和差别。
对于 MySQL 的技术内容，你们还有什么想晓得的吗？连忙留言通知小编吧！
