情况描述：
zabbix proxy其中有一个表，proxy_history 107G，一天增长25G，空间只够两天了(现象是最近用nodate语法配置了大量日志不刷新监控告警) 目前情况如下:

  1. 版本5.1，不支持optimize缩减，5.6支持，原本打算清理冗余数据后缩减。
  2. 打算备份mysql站点，然后truncate表，释放空间(理论影响不大)，需要确认并走流程。
  3. 打算调试proxy 配置文件buffer相关参数，限制增长，但是没达到效果。

和朋友讨论和同事讨论过程忽略...

总结分享：
1、历史数据一般一条记录50字节左右，根据from_unixtime可大致判断数据增长时间（我们这边是用大量nodata配置几分钟告警日志不刷新），监控项很多，数据增长比较快（目前打算自定义key根据日志时间戳监控，以及减少不必要的监控项，观察一段时间）
2、一开始打算备份一下proxy数据库站点（历史数据不是server库没什么影响），然后truncate释放空间。后来同事选择先delete部分删除，结合housekeeper清理机制，减缓其增长（这个要看清理速度和增长速度），比truncate温和，(结合unix_timestamp根据时间清理，zabbix3.x新特性是越来越多)
3、如果选择升级用optimize缩减的话，用脚本定期清理是不错的选择。
4、如果数据量太大，朋友给的意见是采用数据库分区（有一定维护管理难度），生产主机比较多考虑。（zabbix官网有案例）