初次認知是分區問題，分區不夠了，開始在網上查分區創建方法 alter table history partition by range (clock)(partition p1 values less than MAXVALUE); 在此我給了MAXVALUE一個很大的值，執行了20分鐘沒有執行完，發現這種方式不行 檢查是不是設置了自動分區 show create table history; 發現有一大堆以clock的分區，發現clock是日期，正好是今天凌晨，而一上午沒有生成分區，所以導致數據存不進去。知道了原因，先解決，先不探討為什么有自動分區的問題。zabbix 一次慘痛的分區經歷 發現問題了，就先解決問題，創建分區吧 CALL partition_create("zabbix", "history", "p201706140000", 1497456000); 提示沒有這個partition_create存儲過程，所以無法執行，挺納悶，先不解決這個； 創建這個存儲過程，建議參考：https://www.zabbix.org/wiki/Docs/howto/mysql_partition#partition_create ( 網上不靠譜的太多了) 進入數據庫執行下面語句：（root登錄，不知道有沒有影響）
ok，此時把不存在分區的表都創建上，然后重啟zabbix。 現在要查找問題的原因了 因為前面處理zabbix的同事，做了分區分表，然后又在cron內設置了定時任務，定時添加幾天的表區 mysql -uzabbix -pxxx -e "CALL partition_maintenance_all('zabbix');" 因為我接手后，不知道這是什么，把zabbix服務器歸納整理后，mysql密碼變了，執行不了了,消耗了一上午的時間，不過清晰了zabbix分區過程，也是有收獲的 現在要開始總結下分區分表了 查看存儲過程：select specific_name from mysql.proc ; 查看過程邏輯：show create procedure partition_create /G 刪除存儲過程：drop procedure if exists partition_maintenance_all ; 查看存儲過程：show procedure status like 'partition_maintenance%' /G; 修改存儲過程：ALTER {PROCEDURE|FUNCTION} sp_name [characteriss] 根據官方文檔，創建存儲過程，包括：create、drop、maintenance、verify、maintenance_all 最好根據自身情況對maintenance_all，進行修改，用于減輕數據。
