維護表有三個主要的目的：

1、找到并修復損壞的表。

對于MyISAM存儲引擎來說，表損壞通常是系統崩潰導致的。其他的引擎也會由于硬件的問題，MySQL本身的缺陷或者操作系統的問題導致索引的損壞。

損壞的索引，會導致查詢返回錯誤的結果或者莫須有的主鍵沖突等問題，嚴重時還會導致數據庫崩潰。

這類情況，可以嘗試check table來檢查是否發生了表損壞，有些存儲引擎不支持這個命令。

可以使用repair table 來修復損壞的表，但同樣不是所有引擎都支持該命令。

如果引擎不支持，可以使用alter操作重建表，或者將數據導出然后再重新導入。

InnoDB一般不會損壞，如果發生損壞，一般要么是數據庫硬件問題，例如內存或者磁盤問題，要么就是數據庫管理員操作導致。

常見的錯誤是由于嘗試使用rsync備份InnoDB導致的。

如果是某條查詢導致的，那一定是遇到了bug,而不是查詢的問題。

2、維護準確的索引統計信息。

MySQL的查詢優化器會通過2個API來了解存儲引擎的索引值的分布信息，以決定如何使用索引。

第一個API是records_in_range(),通過向存儲引擎傳入兩個邊界值獲取在這個范圍大概有多少條記錄。

對于某些引擎，該接口返回精確值，比方說MyISAM;對于InnoDB則是一個估算的值。

第二個API是info(),該接口返回各種類型的數據，包括索引的基數。

當返回信息不準確的時候，優化器會使用索引統計信息來估算掃描行數。如果表沒有統計信息，或者統計信息不準確，優化器很可能做出錯誤的決定。

可以運行analyze table 來重新生成統計信息。

Memory引擎不存儲索引統計信息

MyISAM將索引統計信息存儲在磁盤中，analyze table 需要進行一次全表掃描，整個過程需要鎖表。

MySQL5.5以后，InnoDB也不在磁盤存儲索引統計信息，而是通過隨機的索引訪問來進行評估并存儲在內存中。

使用show index from 命令可以察看索引基數(Cardinality)

InnoDB會在首次打開表，或者執行analyze table,或者表大小發生變化超過1/16或show table status,或show index時候都會計算索引的統計信息,如果服務器有大量的數據，這會是個嚴重的問題，只要show index查看索引統計信息就一定會觸發統計信息更新，可以關閉

innodb_stats_on_metadata參數來關閉。

一旦關閉自動更新，那么需要周期性的使用analyze table 來手動更新，否則問題大了。

3、減少索引和數據碎片

B-Tree索引可能會碎片化，這會降低查詢效率。碎片化的索引可能會以很差或者無序的方式存儲在磁盤上。

可以通過optimize table 或者導出再導入的方式來重新整理數據。

對于不支持optimize table 的存儲引擎，可以通過一個不做任何操作的alter table來重建表。alter table

也可以先刪除索引，重建表，最后重新創建索引來實現。

索引的介紹就先到這里了，明天進入查詢性能優化部分！

總結

以上是生活随笔為你收集整理的mysql维护索引_高性能的MySQL（5）索引策略-索引和表的维护的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。