共计 635 个字符，预计需要花费 2 分钟才能阅读完成。
问题：
在小伙伴们学习的过程中，执行了一个 insert，而后发现了以下景象：
首先在 binlog 中，发现这条 SQL 运行了 2 秒 (上一问中, 咱们晓得 BEGIN 的 exec_time 等于事务第一个 SQL 的 exec_time，本例中就是 insert 的 exec_time)
但在慢日志中, 发现这条 SQL 的 query_time 为 10 秒:
那么 binlog 和慢日志谁的工夫更精确一些？
试验
首先咱们依照第 02 问的步骤，筹备一个慢 IO 的设施，使读操作和写操作都提早 2000ms（在 02 问中是 100ms，须要调整 dmsetup 那一步的参数），此处省略步骤。
这是咱们的慢 IO 设施和挂载点：
宽油建设一个数据库：
下个 SQL 看看：
察看 binlog，binlog 认为 SQL 执行了 2 秒：
察看慢日志，慢日志认为 SQL 执行了 10 秒：
与咱们问题中的状况雷同。
从试验后果猜想：慢日志更精确一些，而 binlog 中的执行工夫不包含因为 binlog 带来的提早。
原理
MySQL 实际上的执行步骤跟咱们猜想的相似，一个 SQL 波及以下几个工夫点：
1.SQL 开始
2. 记录 general log
3.SQL 解析
4.SQL 执行过程中，生成 binlog event
5.binlog 刷盘
6. 记录慢日志
binlog 中的 SQL 执行工夫，是从 1 到 4 的工夫，而慢日志中的 SQL 执行工夫，是从 1 到 6 的工夫。
本试验中，咱们通过慢 IO 拖慢了步骤 5，使得两个工夫的差别比拟显著。
失常运维过程中，大家也能够通过两个工夫戳的差别，来猜想 binlog 刷盘效率是否出了问题。
