背景
12月1号中午突然收到大量报警，某客户环境操作数据库大量失败，报错信息如下图所示：
这个报错我是第一次见，一时间有点无所适从，但是从字面意思来看是MySQL目前处于LOCK_WRITE_GROWTH状态，拒绝执行当前的语句，一定是MySQL出问题了。
初定位
我随即登录阿里云控制台查看MySQL是否有什么异常，果不其然运行状态那里提示“锁定中（空间不足）”，我根据提示链接简单阅读了阿里云关于锁定状态的解释说明以及处理措施。
以下为阿里云官方内容截取，想了解更多细节的请前往推荐阅读部分第一个链接。
虽说事有蹊跷，但是为了快速恢复服务，来不及深思，立即删除了一部分日志型数据，释放出来10个G左右的空间，几分钟以后数据库状态正常。
剥茧抽丝
服务恢复以后我们兵分两路，一方面联系客户扩容数据库，10G估计撑不了多长时间；另一方面我开始剥茧抽丝般的寻找程序上可能的bug，比如新上了什么功能导致存储过多的数据诸如此类。
通过阿里云监控发现11月30的存储空间占用只有300G，到了第二天中午瞬间增长了150G左右，这很不正常，感觉一定是程序的bug，询问一番以后发现昨晚并没有发版，难道是个历史bug？
怎么揪出这个bug呢，我首先寻找阿里云控制台是否有表粒度的空间变化趋势图，找了一圈没找到，只有整体空间的变化趋势，似乎对排查不利，但其中一个细节引起了我的注意，请看下图。
已总空间≠数据空间+临时空间+日志空间，有150G左右的空间被狗吃了？带着问题我又找到了另一张监控，可以初步解释那150G去哪了。
这张图中多出来一个“mysql.other.size”，有157G左右，和上面被狗吃掉的150多G高度吻合，成功引起了我的注意，但mysql.other.size到底所谓何物？
真相
接下来我提工单给阿里云工程师询问这一情况，一起看看专业人士的解答。
慢查居然还能导致数据库空间满，也算是弥补了我数据库知识的又一片空白。
看下官网的一篇“RDS MySQL临时文件导致实例磁盘空间满且出现“锁定中”状态”的相关描述（推荐阅读第二个链接）。
事后我们重启了数据库，临时表空间释放出来150G，随即叫停了扩容。
接下来需要清理一波慢查，避免悲剧再次发生。
