刚刚接触MYSQL不久，编码规范意识欠缺，近期一项工作中因操作查询不当，导致数据库空间爆满，直至锁库，导致数据库重启。
环境：阿里RDS MySQL 5.7
空间爆满直接原因：数据库系统文件空间使用量超出数据库空间，如图：
临时解决方案：重启数据库（如果可以的话，其他暂时也没有其他好的办法）
遇到问题后，首先对‘系统文件空间’这个概念进行了咨询：
如果目前看不到哪个文件导致的，一般情况是
ibdata1 文件由于长时间不结束的查询导致ibtmp1文件过大导致，该文件存放临时文件，分组，排序，关联就会产生临时文件。
重启会释放临时文件，ibtmp1空间就会释放。例如慢日志里的这种大sql
问题又来了，ibdata1和ibtmp1又是什么？
接着收集资料：
https://baijiahao.baidu.com/s?id=1612955427840289665&wfr=spider&for=pc
可以参考的原文链接放上了，百度的，看个人理解了，我就不误导人了。
既然，ibdata1和ibtmp1这两个临时文件，没有好的办法快速清除，那么只好从‘长时间不结束的查询’搞起吧。
首先，回忆了下问题出现的1小时内的动作，哦哦哦，想起来了，有一个长SQL查询，几分钟没反应，然后我就手动停止了，我用的Navicat工具，如图：
毕竟已经运行了几分钟了，关闭的时候，卡了一会就恢复正常了，然后去搞其他事情了。事实上，这段SQL在我点击“停止”之后，在服务器端没有正常终止，导致一直在执行，后来发现数据中有关联项中存在大量null值和重复项，猜测是导致了数据“笛卡尔积”，产生了大量的临时数据文件。
既然是这样的场景，那么我首先想到的是，限制临时计算空间的大小
ibtmp1目前没有参数可以调节
既然如此，那我限制一下查询的时长吧
参数1：interactive_timeout ；参数2：wait_timeout
mysql在关闭一个交互式/非交互式的连接之前所要等待的时间。建议不需要设置太长的时候，否则会占用实例的连接数资源。
在控制台，参数设置修改，然后提交参数
后续维护动作
避免出现执行效率很差的SQL大量执行的情况。
尽量在业务低峰期进行索引创建删除、表结构修改、表维护和表删除操作。
建议监控和清理执行时间过长的会话或事务。
最终，没有实际的解决问题，只是变相的反应出，我需要进行SQL优化了
关于执行计划的分析，这篇文章讲的挺好挺好的~很容易理解
下篇记录下SQl的优化内容吧，主要是看执行计划和调整实现逻辑。记录生活吧，不然不长记性啊。。。