情況描述：
zabbix proxy其中有一個表，proxy_history 107G，一天增長25G，空間只夠兩天了(現象是最近用nodate語法配置了大量日誌不刷新監控告警) 目前情況如下:
- 版本5.1，不支持optimize縮減，5.6支持，原本打算清理冗餘數據後縮減。
- 打算備份mysql站點，然後truncate表，釋放空間(理論影響不大)，需要確認並走流程。
- 打算調試proxy 配置文件buffer相關參數，限制增長，但是沒達到效果。
和朋友討論和同事討論過程忽略...
總結分享：
1、歷史數據一般一條記錄50字節左右，根據from_unixtime可大致判斷數據增長時間（我們這邊是用大量nodata配置幾分鐘告警日誌不刷新），監控項很多，數據增長比較快（目前打算自定義key根據日誌時間戳監控，以及減少不必要的監控項，觀察一段時間）
2、一開始打算備份一下proxy數據庫站點（歷史數據不是server庫沒什麼影響），然後truncate釋放空間。後來同事選擇先delete部分刪除，結合housekeeper清理機制，減緩其增長（這個要看清理速度和增長速度），比truncate溫和，(結合unix_timestamp根據時間清理，zabbix3.x新特性是越來越多)
3、如果選擇升級用optimize縮減的話，用腳本定期清理是不錯的選擇。
4、如果數據量太大，朋友給的意見是採用數據庫分區（有一定維護管理難度），生產主機比較多考慮。（zabbix官網有案例）