Zabbix 數據清理的一系列操作
基本信息：
Zabbix 版本 4.0.9
MySQL 版本 5.5
一、問題
我們將 Zabbix 的數據存放在測試環境的 RDS (阿里雲)上，但是這個 RDS 購買的時候就只有 10G 的存儲，所以監控沒有幾個月，我們的數據庫就報存儲空間不足的預警了。
首先進行排查，是哪些表占用的存儲空間比較多呢，我們發現主要是 history 和 history_uint 這兩個表。占用空間最大的是 history_uint表。
那么這兩個表分別是存儲什么內容呢？
history_uint
該表存儲的是監控項的無符號整型的數據。
該數據的保存時長，取決於在監控項設置的 歷史數據保留時長。
CREATE TABLE `history_uint` (
`itemid` bigint(20) unsigned NOT NULL,
`clock` int(11) NOT NULL DEFAULT '0',
`value` bigint(20) unsigned NOT NULL DEFAULT '0',
`ns` int(11) NOT NULL DEFAULT '0',
KEY `history_uint_1` (`itemid`,`clock`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
-
itemid 是 監控項 ID
-
clock 是數據的時間的時間戳(unix)
-
value 是監控項對應的數據值
-
ns 是 納秒時間值(小於1s的值)，
監控項的精確實際收集時間，是由 clock + ns 組成的。
history
這個表保存的是浮點型的。
像 history_str 等保存的是 字符型數據。這些都是我們在設置監控項的對應的信息類型決定的。
該數據的保存時長，取決於在監控項設置的 歷史數據保留時長。
擴展
表 trends 是保存了趨勢數據用的，和 history 不同的是，trends 表僅僅保存了
小時平均的值。所以 trends 表也有很多的類型，對應history。
二、解決辦法
臨時解決辦法
針對這個問題，我們臨時的解決辦法就是，就刪除 history_uint 和 history 的一些歷史數據。
首先獲取要刪除時間的一個時間戳，比如我們要刪除 2019年 9月10號 11點00之前的數據。那么這個時間對應的時間戳是 1568084400.
我們進行刪除 history_uint 里的數據，這里需要注意一個點，如果我們的數據量比較多的話，我們建議分多個時間段進行刪除，比如我們數據庫里面由 2018年 10月份到2019年10月份的數據 ，那么我們可以將里面的數據分成4個階段進行刪除，從 2018年10月份到 2019年1月份，從 2019年1月份到 2019年4月份，這樣就可以避免一次性刪除數據過多導致數據庫的負載比較大。(或者也可以使用 limit 10000)
delete history_uint
delete from history_uint where clock < 1568084400 LIMIT 10000;
delete history
delete from history where clock < 1568084400 LIMIT 10000;
在執行完上面的刪除操作之后，我們發現一個很異常的事情發生了。
就是我們刪除了那么多的數據，但是數據的儲存空間是沒有減少的。反而增加了(這不是由於新增加的數據導致，后面覺得是阿里雲的顯示不准確).
原因是 :
對於delete from table_name where xxx帶條件的刪除, 不管是 innodb 還是 MyISAM 都不會釋放磁盤空間.
為什么delete where 刪除空間不會減少? 舉個例子,一個公司有 100個工位,有100個人坐着,當有50個人離職了,但是他們的工位還是存在的,只有在把工位拆除了才會不存在, 它們的工位也是可以安裝新入職的員工的.
所以我們需要進行 OPTIMIZE TABLE 操作,進行釋放空間.
注意: 在optimize table '表名'運行過程中，MySQL會鎖定表。
OPTIMIZE TABLE history_uint;
OPTIMIZE TABLE history;
在 RDS 操作完之后, 我們大概需要過幾分鍾才能在控制台看到我們的實際儲存信息.
借鑒內容: https://blog.csdn.net/weixin_40596063/article/details/82978736
1、drop table table_name 立刻釋放磁盤空間 ，不管是 Innodb和MyISAM ，不保留表結構，;2、truncate table table_name 立刻釋放磁盤空間 ，不管是 Innodb和MyISAM 。truncate table保留表結構，刪除方式類似drop table;3、delete from table_name刪除表的全部數據,對於MyISAM 會立刻釋放磁盤空間 ,InnoDB 不會釋放磁盤空間;4、對於delete from table_name where xxx帶條件的刪除, 不管是innodb還是MyISAM都不會釋放磁盤空間;5、對於delete操作（或帶條件的delete）需要釋放空間，在delete以后使用optimize table table_name 會立刻釋放磁盤空間。不管是innodb還是myisam ；所以要想達到釋放磁盤空間的目的，delete以后執行optimize table 操作。對於delete之后未釋放的空間。在insert時無需新開辟空間。會使用保留空間 。
永久解決辦法
- 數據量過多是由於我們保存的歷史數據的時間過長，我們可以設置 歷史數據的保留時長，將該值設置的更短一些，這樣數據量也就隨着減少了。
- 擴大數據庫的儲存空間。