我搜索了之前的问题，但找不到与我的问题完全匹配的内容:
在查询事务期间的哪个点设置二进制日志时间戳，然后将其写入二进制日志？
上下文:我一直在使用一个使用主/从复制的数据库。通常，从属服务器会落后于主服务器，我确信这仅仅是因为二进制日志中存在大量共享相同时间戳的事务。当我说很多时，我指的是 1 小时日志中超过 9000 个条目的 150 多个时间戳(加上返回的 9000 个条目以下的其余内容)。这是使用以下方法发现的:
mysqlbinlog bin-log.0001 | grep 'TIMESTAMP' | uniq -c | awk '{if ($1>9000){print $0}} ' | sed -e 's/\/\*\!\*\/;//g' | gawk -F '=' '{cmd="date -d @"$2; cmd | getline d; print $1"="$2"\t("d")"; close(d)}'
所以我基本上是想弄清楚共享时间戳的事务数量是否反射(reflect)了主服务器上的工作负载，以及这些数字是否异常。
绘制 Second_behind_master 图表时，它显示线性增长，然后突然下降，这似乎表明了同样的情况。
MySQL 版本是 5.6.33。
最佳答案
导致“从属滞后”的可能原因有很多，在此很难详细回答。二进制日志时间戳写入事务开始时。
这里有一篇有用的文章，详细介绍了如何确定症状的原因:https://www.percona.com/blog/2014/05/02/how-to-identify-and-cure-mysql-replication-slave-lag/例如，它解释了 Seconds_Behind_Master 参数如何产生误导，因为它仅测量最近执行的中继日志的时间戳与 IO_THREAD 最近下载的中继日志条目之间的差异。
您会在该网站上找到许多可能对您有帮助的其他资源。这包括博文中提到的 Percona 工具包，它与所有 Percona 软件一样完全免费且开源。
披露:我在 Percona 工作。
关于mysql - MySQL binlogs中的时间戳是什么时候设置的，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/47631727/