mysql 索引碎片

簡單的說，刪除數據必然會在數據文件中形成不連續的空白空間，而當插入數據時，這些空白空間則會被利用起來。因而形成了數據的存儲位置不連續，以及物理存儲順序與理論上的排序順序不一樣，這種是數據碎片。     實際上數據碎片分爲兩種，一種是單行數據碎片，另外一種是多行數據碎片。前者的意思就是一行數據，被分紅N個片斷，存儲在N個位置。後者的就是多行數據並未按照邏輯上的順序排列。     當有大量的刪除和插入操做時，必然會產生不少未使用的空白空間，這些空間就是多出來的額外空間。     索引也是文件數據，因此也會產生索引碎片，理由同上，大概就是順序紊亂的問題。     Engine 不一樣，OPTIMIZE 的操做也不同的，MyISAM 由於索引和數據是分開的，因此 OPTIMIZE 能夠整理數據文件，並重排索引。     InnoDB 使用的 Clustered Index，索引和數據綁定在一塊兒，重排序是不現實的。因此不支持 MyISAM 式的 OPTIMIZE，而是綁定到了 ALTER TABLE 命令上面。當執行優化操做時，實際執行的是一個空的 ALTER 命令，可是這個命令也會起到優化的做用，它會重建整個表，刪掉未使用的空白空間...     OPTIMIZE 操做會暫時鎖住表，並且數據量越大，耗費的時間也越長，它畢竟不是簡單查詢操做。 因此把 Optimize 命令放在程序中是不穩當的，無論設置的命中率多低，當訪問量增大的時候， 總體命中率也會上升，這樣確定會對程序的運行效率形成很大影響。     比較好的方式就是作個 Script，按期檢查 `information_schema`.`TABLES`，查看 DATA_FREE 字段，大於0話，就表示有碎片。腳本多長時間運行一次，能夠根據實際狀況來定，好比每週跑一次。