• 产生大量undo日志撑满磁盘空间导致MySQL不可用；

• 定义大量用户变量耗尽MySQL的内存；

• 触发MySQL的bug。

声明： 这里介绍的三种方式可以搞挂目前大多数的线上MySQL实例，请谨慎测试。一切后果，本文作者及本订阅号概不责任哦。

众所周知，InnoDB是一个支持MVCC的存储引擎，为了支持MVCC，InnoDB需要保存undo日志，以便对用户提供记录的历史版本。如果我们开启一个事务，反复地更新一条记录而不提交，会怎么样呢？将会产生大量的undo日志，使得磁盘空间爆满，导致MySQL不可用。

在innodb现有的实现中，并没有对单个用户或单个连接使用的undo空间进行限制。也就是说，我们只需要反复更新一条记录，而不提交，就会产生大量undo日志。由于我们的事务没有提交，undo日志不能被回收，从而使得磁盘空间被耗尽，最终导致MySQL挂掉。

Jeremy Cole老早就提到过这个问题，不过该问题至今还存在。要进行该项测试，只需要有更新记录的权限即可。测试脚本如下：

测试过程中，可以观察磁盘空间的使用率，一直在上升：

磁盘空间满以后，再执行SQL语句就报错了，错误信息如下：

错误日志如下：

可以看到，虽然MySQL进程还存在，其实服务已经不可用了。事务在执行过程中，会产生undo日志以及binlog日志，占用磁盘空间，如果我们在线上执行一个大事务，就需要留意是否有可能因为undo和binlog导致磁盘空间爆满的情况。为了规避风险，我们还是应该尽可能地避免特别大的事务。

上面的例子并没有真的让MySQL进程挂掉，而且需要对数据库具有写的权限。你可能不服，那么，我们再来看另外一种情况，即定义大量的用户变量。

这种方式将会导致MySQL占用的内存急剧上涨，最后被操作系统kill掉。而且，不再需要有更新记录的权限，只需要有登录数据库的权限即可。

测试脚本如下：

我们不断地定义用户变量，可以通过pidstat观察MySQL占用的内存：

可以看到，MySQL占用的内存越来越大，最后，MySQL进程不在了。通过dmesg可以看到，是由于MySQL占用内存太多，被操作系统kill掉：

上面的例子演示了一个普通用户耗尽资源，导致MySQL被操作系统kill掉的情况。其实，这个问题是完全可以避免的。MySQL支持在创建用户的时候，限制用户使用的资源。

可以限制的资源包括：

• 每小时的查询次数

• 每小时的更新次数

• 每小时的连接次数

• 同时建立的连接数

使用方式如下所示：

虽然MySQL支持限制用户使用的资源，但是，在实际使用过程中，很少有人会去限制用户使用的资源，甚至很多用户根本不知道MySQL提供了这样的功能，这给”不法分子”有了可乘之机。

可以说，写MySQL的都是一群科学家，并且，MySQL使用如此广泛，遇到MySQL的bug应该不容易。不过，只要是程序就有可能存在bug，所以，遇到MySQL的bug也不是不可能的情况。如果看MySQL的release note，每次的新版本都会修复无数的bug。尤其以新功能的bug居多。

这一节，我们来测试一下MySQL的bug。即在使用grant授权时，如果使用了一个很长的数据库名，将导致MySQL挂掉。之所以选择这个bug，是因为该bug复现起来特别容易了，只需要执行一条SQL语句即可。

如下所示：

很明显，该问题是由于缓冲区溢出导致，这也是我们编程中容易犯的一个错误。这个bug在MySQL 5.7中已经修复，我在5.6.19中进行测试，MySQL立马挂掉，可以说是搞挂MySQL的最快方式。

在本文中，我演示了三种搞挂MySQL的方式，这三种方式的思路不同，涉及到的知识点也不一样。将这三种方式都尝试一遍，可以搞挂正在使用的无数MySQL实例。那么，是不是说MySQL特别脆弱，非常容易被搞挂呢？答案是否定的。MySQL在各互联网公司广泛使用，已经经受住了无数的考验。

本文之所以显得MySQL容易被搞挂，主要还是因为大部分人的使用姿势不当，以及对MySQL的了解不足所导致的。要避免MySQL挂掉，这里有几点建议：

• 特别大的事务会占用特别多的资源，甚至出现占满磁盘空间的情况，要避免特别大的事务；

• 限制用户使用的资源，避免不良用户恶意破坏；

• 紧随社区的脚步，关注社区报告和修复的bug，必要时升级数据库版本，以免遇到已知bug；

• 新功能一般bug较多，不要上得太快，避免踩到未知bug。

作者介绍  赖明星

• 网易杭州研究院资深开发工程师，网易RDS项目的核心开发人员；

• 负责大型数据库实例的云端解决方案的模块设计和功能开发，对关系型数据库和NoSQL数据库具有浓厚的兴趣。

• 往期作品：《网易这样用sys schema优雅提升MySQL易用性》