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 …
本文也有英文版：English version。
MySQL官方从MySQL-5.6开始优化复制延迟问题，最先实现了 Schema 级别的 Binlog
并发应用。然而这个并发能力并不能解决日常的复制延迟。然后官方在
MySQL-5.7上实现了基于提交顺序的并发回放策略(Commit Order),
这种策略依赖主上的事务并发执行数量。主上并发执行的事务非常多的情况下，从库上回放的速度才会快。如果主上并发少，从库上回放速度仍然会变慢，产生复制延迟。因此官方又在
MySQL-5.7 上又实现了行级的并发策略(Writeset),
这种并发策略无论主上并发事务的多少，都能在从库上快速的并发回放。
我们很早以前就在线上全面使用了基于 writeset 的复制策略，writeset …
[获取更多]
大事务是MySQL中一个痛点问题， 不仅会带来复制延迟，也会带来大量的稳定性问题。上一篇文章《MySQL大事务提交优化》介绍了大事务在提交时带来的问题，以及AliSQL中做的技术优化。这篇文章会介绍大事务在半同步复制时的问题，以及AliSQL中如何解决这个问题。
在《MySQL大事务提交优化》中，我们提到大事务提交时写Binlog会导致系统出现如下奇怪的慢SQL。
1.3s，并且慢SQL记录里也没有看到长时间的锁等待。
本文也有英文版：English version。
在使用和运维MySQL的过程中你一定碰到过下面这种奇怪的慢SQL。
1.3s，并且慢SQL记录里也没有看到长时间的锁等待。
1.3s。
当这种情况出现时，最有可能的就是有大事务在提交。以下是一个模拟测试的结果，我们用Sysbench来模拟正常的业务，然后在后台每5秒执行一个大的UPDATE，可以看到大的UPDATE会严重的影响业务的性能。
根因分析
上图展示了两个事务的执行过程：