Ideas, releases, practical guides, and perspectives from the people building with MySQL.
本文也有英文版：English version。
你有没有碰到过 mysqld 进程启动了很长时间也起不来的情况？这时候我们可以用 perf top
命令查看一下 MySQL 进程主要在干什么事情。如果你查看到的信息如下图所示，启动过程中 MySQL 的
主线程(mysqld_main函数开始的线程)
绝大多数的时间都花在了回滚事务上，那么很可能是遇到了大事务回滚。
这种情况最常见的一个场景是一个大事务在写 Binlog 时把磁盘空间占满了，导致了实例的宕机重启。我曾经遇到的最大的 Binlog
文件超过了 114GB。由于 Binlog Cache 的临时文件在写完 Binlog
后才被清理，所以这个事务总共占用了 228GB 的空间。MySQL 的参数
binlog_error_action …
大事务是MySQL中一个痛点问题， 不仅会带来复制延迟，也会带来大量的稳定性问题。上一篇文章《MySQL大事务提交优化》介绍了大事务在提交时带来的问题，以及AliSQL中做的技术优化。这篇文章会介绍大事务在半同步复制时的问题，以及AliSQL中如何解决这个问题。
在《MySQL大事务提交优化》中，我们提到大事务提交时写Binlog会导致系统出现如下奇怪的慢SQL。
1.3s，并且慢SQL记录里也没有看到长时间的锁等待。
本文也有英文版：English version。
在使用和运维MySQL的过程中你一定碰到过下面这种奇怪的慢SQL。
1.3s，并且慢SQL记录里也没有看到长时间的锁等待。
1.3s。
当这种情况出现时，最有可能的就是有大事务在提交。以下是一个模拟测试的结果，我们用Sysbench来模拟正常的业务，然后在后台每5秒执行一个大的UPDATE，可以看到大的UPDATE会严重的影响业务的性能。
根因分析
上图展示了两个事务的执行过程：