一问一实验 头图.png

本文关键字:大事务、binlog、Linux

问题

我们并不喜欢 MySQL 中出现大事务(更新很多数据的事务),大事务往往带来很多维护的问题。

我们在维护 MySQL 时,需要关注于是否出现了较大事务,在 binlog 里找到其出现的证据。

实验

我们先创建个数据库:

1.png

这里我们启用了 GTID,对于非 GTID 的 binlog,大家也可以用类似的方法处理。

下面需要创建一些大小不同的事务,我们使用在 第11问 里使用过的手法,

2.png

反复执行,

3.png

下面我们开始研究 binlog,先解开一段看一下,

4.png

我们知道在 GTID 模式下,事务开头必然会有一个 GTID_event,如图中红框标注。

我们就过滤这一段信息,

5.png

这里用到了 grep 两个技巧:

  1. 过滤 tab 字符,用到了 "$(printf 't')" 来插入 tab 字符,无法直接使用 "t" 字符。
  2. 使用 -B 参数向前找到了匹配的前一行,输出 "at xxx",这一行是 GTID_event 在 binlog 中的位置(单位是字节)。

然后我们将其中的位置信息过滤出来,

6.png

再将每两行的位置减一下,就获得了每一个事务在 binlog 中的大小,

7.png

将这些事务的大小排序一下,取最大值,

8.png

这是这个 binlog 中最大的 10 个事务的大小,可以看到最大的事务在 binlog 中占用了 658k 大小,不算太大。

本期没有关于 MySQL 太多的知识点,只是活用 Linux 的命令,可以简单高效获取 binlog 的信息。

下面附上本期命令的文字版:

~/opt/mysql/5.7.20/bin/mysqlbinlog data/mysql-bin.000001 | grep "GTID$(printf '\t')last_committed" -B 1 \

关于 MySQL 的技术内容,你们还有什么想知道的吗?赶紧留言告诉小编吧!
黄炎自媒体.png


爱可生开源社区
426 声望207 粉丝

成立于 2017 年,以开源高质量的运维工具、日常分享技术干货内容、持续的全国性的社区活动为社区己任;目前开源的产品有:SQL审核工具 SQLE,分布式中间件 DBLE、数据传输组件DTLE。