為了擁有高效能的資料庫，建立良好的表結構以及索引是必不可少的，與此同時對於表以及索引的維護也很重要
資料庫表損壞的原因很多，作業系統問題，硬體問題，或者是手工的修改了mysql的資料檔案，都會導致表的損壞。當出現問題時可能會導致查詢行為的異常，具體的異常行為在不同版本的資料庫中都不同。
當發現資料庫的表行為有異常時，可以使用check table testable;（不是所有的資料庫引擎都支援）來進行檢查，當檢測到異常時 可以使用repair table testable;（不是所有的資料庫引擎都支援）來進行修復，如果儲存殷勤不支援repair table,可以使用alter table testableengine=innodb的方式來進行修復。
下面以dictionary表為例，演示在innodb中的操作（不支援repair table）
除了操作的失誤（誤刪資料或表），當資料庫的表出現異常時，也往往會伴隨著資料的丟失。當悲劇發生時，除了想辦法找到丟失的資料以外，還要找到出現資料丟失的根源
可以通過以下的兩種方式來找回丟失的記錄，不同儲存引擎的恢復策略會不同
（1） 使用mysql自帶的工具集（
（2） 當第一種方法無效時，使用專業的工具集（percona data recovery tool for innodb：
在每個資料庫的查詢操作中，查詢優化器會更具當前資料庫的綜合情況（例如，cache,index,表資料等）提供最優的執行計畫。在mysql中，針對index查詢優化器會通過record_in_range()以及info()兩個ａｐｉ 函式來了解儲存引擎中索引的分布情況，從而決定如何使用索引。如果這兩個函式返回的資訊不足以讓優化器來使用，查詢優化器會根據「索引統計資訊」來進行優化。
當索引的統計資訊也不準確時，可以通過執行 analyze table來重新索引統計資訊。
索引的統計資訊維護在儲存引擎層實現，不同的儲存引擎實現方式是不同的，下面以innodb為例進行分析。
在mysql 5.5 版本的innodb中，索引的統計資訊沒有儲存在磁碟中，而是採取隨機抽樣索引頁的方式進行分析，並且把抽樣分析的結果放在記憶體中。老版本中會抽取8個索引頁，在5.5以及更新的版本中可以通過innodb_stats_sample_pages引數來制定抽樣的數量，可以通過來了解該引數的具體資訊
當進行下列操作時，innodb的索引統計資訊會重新計算
· 首次開啟表
· analyzetable
· 表發生明顯的大小變化（空間超過1/16或者是插入了20億條記錄）
當進行下列操作時，innodb的索引統計資訊會得到更新
· 開啟某些information_schema表
· 執行show table status from testdb
· 執行show index form testable;
· 客戶端開啟了統計資訊自動補齊功能
當資料庫的資料量比較大時，頻繁的執行索引統計新的的計算以及update是非常的消耗資源的，尤其是執行show table status操作時一定會觸發更新動作，為了避免對效能產生影響，可以通過
set globalinnodb_stats_on_metadata=off(or0).
來解決該問題。
在其他的資料庫產品中(percona)還可以通過使用innodb_stats_auto_commit引數關掉索引統計資訊自動更新的功能，或者是使用持久話的技術來維護索引統計資訊。
對與索引碎片，b-tree索引會產生儲存碎片，過多的碎片會對查詢的效能造成很大的影響。
對於表碎片，innodb會產生行間碎片，和索引碎片一樣，過多的表碎片也會對效能產生影響。
optimizetable 可以整理index以及表的碎片，但是只支援myisam
,innodb
, and archive 。
由於innodb支援optimize table語法，所以可以使用以下的方式來對innodb的表進行優化：
截圖中出現的「table does notsupport optimize, doing recreate + analyze instead」可以不用關注。
對於不支援optimize table語法的儲存引擎，可以手工的通過(drop/crete index+alter tabletestable engine=…)的方式來清理碎片
高效能MySql演化論 十一 常見查詢語句的優化
高效能mysql演化論 十一 常見查詢語句的優化，總結一下常見查詢語句的優化方式。1.count的作用 count table.filed 統計的該字段非空值的記錄行數 count 或者是count not nullable field 統計的是全表的行數 如果要是統計全表記錄數，count 效率會...
高效能MySql演化論 三 ID 標示符 的選擇
在設計資料庫表結構的時候，通常情況下每張表結構都有乙個字段作為id，因為 id會被用來做查詢，join,fk等操作，所以id設計的好壞對效能的影響很大。在為id選擇合適的型別的時候不僅需要考慮這種型別在資料庫中儲存所占用的空間，還需要考慮該型別在計算或者是值比較時的特性，例如bit型別儲存的時候是二...
高效能MySql演化論 三 ID 標示符 的選擇
在設計資料庫表結構的時候，通常情況下每張表結構都有乙個字段作為id，因為 id會被用來做查詢，join,fk等操作，所以id設計的好壞對效能的影響很大。在為id選擇合適的型別的時候不僅需要考慮這種型別在資料庫中儲存所占用的空間，還需要考慮該型別在計算或者是值比較時的特性，例如bit型別儲存的時候是二...