維護表有三個主要的目的：
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來重建表。
1
altertable<table> engine=;
也可以先刪除索引，重建表，最後重新建立索引來實現。
索引的介紹就先到這裡了，明天進入查詢效能優化部分！
高效能MySQL 5 建立高效能的索引
儲存引擎使用索引 1 在索引中找到對應值，2 據匹配的索引記錄找到對應資料行。雜湊索引 hash index 基於雜湊表實現，只有精確匹配索引所有列的查詢才有效，只有memory 引擎顯式支援雜湊索引。雜湊索引的限制 innodb有 自適應雜湊索引 當某些索引值被非常頻繁使用時,會在記憶體中基於b ...
mysql 高效能索引策略
三 合適的 聯合 索引列順序 四 覆蓋索引和索引覆蓋 五 冗餘和重複索引 索引列不能是表示式的一部分，也不能是函式的引數。對於blob text或很長的varchar型別的列，必須使用字首索引，因為mysql不允許索引這些列的完整長度。字首索引一般適用於 like 查詢，無法使用字首索引做order...
mysql高效能索引 mysql高效能索引（ ）
在開發中，我們知道大多數應用的瓶頸在於sql語句的執行時耗，在這裡並不討論sql語句的安全，僅僅討論高效能sql語句，而與高效能sql語句緊密相連的就是傳說中的 索引。索引 一種工作在儲存引擎端的用於快速找到記錄的一種資料結構。mysql使用索引的方式是 先找到索引的值，再根據索引的值找到資料行。索...