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

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

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

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

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

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

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

InnoDB一般不會損壞，如果發(fā)生損壞，一般要么是數(shù)據(jù)庫硬件問題，例如內(nèi)存或者磁盤問題，要么就是數(shù)據(jù)庫管理員操作導致。

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

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

2、維護準確的索引統(tǒng)計信息。

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

第一個API是records_in_range(),通過向存儲引擎?zhèn)魅雰蓚€邊界值獲取在這個范圍大概有多少條記錄。

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

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

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

可以運行analyze table 來重新生成統(tǒng)計信息。

Memory引擎不存儲索引統(tǒng)計信息

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

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

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

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

innodb_stats_on_metadata參數(shù)來關閉。

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

3、減少索引和數(shù)據(jù)碎片

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

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

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

alter table <table> engine=<engine>;

也可以先刪除索引，重建表，最后重新創(chuàng)建索引來實現(xiàn)。

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

轉(zhuǎn)載于:https://blog.51cto.com/janephp/1314057

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。