-
产生大量undo日志撑满磁盘空间导致MySQL不可用；
-
定义大量用户变量耗尽MySQL的内存；
-
触发MySQL的bug。
声明： 这里介绍的三种方式可以搞挂目前大多数的线上MySQL实例，请谨慎测试。一切后果，本文作者及本订阅号概不责任哦。
一、产生大量的undo日志
众所周知，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的bug
可以说，写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。
扫一扫
283
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
