一、 故障经过
1. 故障现象
收到告警mysql服务器剩余空间突然变成0了，赶紧登上去看了下，发现binlog突然增长10几G，由于服务器磁盘本身不大，就被占满了。登录mysql发现有两个可疑的全表delete慢sql：delete from tabname 在执行，恰好开发来问业务表删除特别慢怎么办，基本确定了是由于开发全表delete数据导致的问题。
2. 故障处理
把delete语句kill掉；手动清理几个binlog释放空间；待从库同步后清理异常增长10几G的大binlog。之后故障恢复。
3. 望文生义
以上其实就是很普通的全表delete大事务产生了过多binlog导致磁盘空间满的问题。
处理完在问开发为什么全表删除不用truncate要用delete的时候，开发反馈是通过Navicat工具图形化界面执行的，看到有一个“清空表”选项，按照平时的说法清空指的就是truncate，于是选择了“清空表”选项。然而实际上，Navicat的“清空表”指的是delete全表，“截断表”才是truncate操作。望文生义，没有仔细了解图形化工具各项含义，导致了这次故障。图形化工具虽然方便，但是没法直接看到各个选项背后对应的语句，尤其是经过翻译的中文版，更难看出实际对应的是什么操作。在执行修改操作时很容易踩坑，务必慎重。可以的话建议修改操作还是自己写命令，清楚知道自己在做些什么为好。
二、 Navicat 清空表 vs 截断表区别对比
其实主要也就是mysql delete全表与truncate的对比：
1. 对应SQL不同
- 清空表： DELETE FROM table_name ;
- 截断表： TRUNCATE [TABLE] table_name ;
2. 返回值不同
- 清空操作，会返回删除的行数
- 截断操作，返回0
3. 自增字段处理
- 清空操作：不会重置自增字段，继续保留最大值。
- 截断操作：自增字段值重置为初始值。
4. 效率比较
- 清空操作： 会扫描全表，表数据越多删的越慢。
- 截断操作：不扫描全表，效率高，几乎与表数据无关。 （相当于重新创建了表，只保留了表的结构，然后删除掉原有表，效率非常高）
5. 日志记录
- 清空操作：会记录日志，可恢复。
- 截断操作：不记录日志，无法恢复。 谨慎使用！
6. 触发器影响
- 清空操作：相当于执行 DELETE删除语句，会激活触发器。
- 截断操作：直接对表的操作，不会激活触发器。
参考