记在前面
事故描述
凌晨阿里云rds实例空间满了，导致rds只有读的权限，不能写。大量写操作失败。
订单阿里云日志大量报警（钉钉和短信），凌晨两点已经发生了，但运维没有重视，忽略了。直到早上7点，看到业务报警后开发反馈给运维（打电话），运维临时将db存储空间扩容，由200G扩容到300G，服务可用，但是原因未找到
事故排查
该数据库实例上有十多个库，首先排除是哪个库的问题
公司核心业务就是一个库，其他库业务量不大，首先想到应该是核心业务库出问题，同时找其他库负责人去核对该时间点有没有大量sql或者大sql操作。
同时给阿里云提工单，阿里云反馈是业务上或客户端执行了大SQL，其中有排序操作，当在内存排序无法完成时会写临时文件，5.7的临时文件被撑大后只能重启数据库进行压缩，5.6的临时文件会随着SQL结束而自动删除。
生产环境用的是mysql 5.7。最近几天核心业务没有做上线操作，应该不是核心业务操作的，猜想是其他业务影响造成的。
后续再次提工单，阿里云回复如下
结合阿里云的提示，最后是在阿里云后台rds上慢查询通过一个排序找到原因，BI连的主库，一个超复杂sql引起的。
后面排查性能问题要结合阿里云后台来，查慢sql还是很容易定位的。
总结
- 运维要重视基础设施报警
- 结合阿里云后台快速定位问题
- 核心业务数据库实例上把其他库迁移走，不要影响核心库