其他一些關於索引的話
建立索引
* 所建立的索引最好支持多種過濾條件 *
* 在所建立的索引列上避免多個範圍條件 *
* 過濾數據的同時最好能照顧到排序 *
維護索引和表
找到並修復損壞的表 ( corruption )
分爲 * 索引損壞 * 和 * 數據損壞 *
check table 來檢查是否發生了表損壞 (MyISAM友好)
repair table 修復損壞的表 (MyISAM友好)
InnoDB 表 alter table t1 ENGINE=INNODB; 來重建表.
如果數據損壞了, 恢復備份吧.
維護索引統計信息
mysql 的查詢優化器會通過兩個API接口 records_in_range() 和 info() 提供的索引值分佈信息, 來決定
如何使用索引.
records_in_range(): 通過向存儲引擎傳入兩個邊界值 來獲取 這個範圍大概有多少條記錄.
MyISAM 返回精確值: InnoDB 返回估算值.
info(): 返回各種類型的數據, 索引的基數(每個索引有多少條記錄)等等.
* mysql 優化器使用基於成本的模型, 衡量成本的主要指標就是一個查詢需要掃描多少行. 所以, 如果 mysql 優化器 records_in_range() 和 info() 提供的信息不準確. 那麼優化器可能做出錯誤的決定.*
ANALYZE TABLE —> 重新生成統計信息
- Memory 引擎不存儲統計信息
- MyISAM 將統計信息 存儲在 磁盤中, ANALYZE TABLE 需要進行一次全索引掃描來計算索引基數. (整個過程會鎖表)
- mysql5.5 及其以前的版本, InnoDB 不保存索引統計信息在磁盤, 而是通過隨機的索引訪問進行評估並保存在內存中.
ps: InnoDB 在首次打開表, 或是 執行 ANALYZE TABLE , 或是 表的大小發生了非常大的變化(大小變化超過了1/16或插入了20億行數據) 的時候計算索引的統計信息. * 在表的數據量很大時, 這可能會產生嚴重的性能問題, I/O 和 鎖 *
減少碎片
* 索引的碎片 * 和 * 數據的碎片 *
* 索引的碎片化 * 會降低查詢效率, 尤其是 範圍查詢, 索引覆蓋掃描等.
* 數據的碎片 *
* 行碎片: 單條數據行 被存儲在多個地方的多個片段中. (根據 id 去訪問一條數據行, 也會產生影響)
* 行間碎片: 多個數據行之前 不是被順序的存儲在磁盤中. (對全表掃描和聚簇索引掃描有很大影響影響)
* 剩餘空間碎片: 硬盤上的 ‘數據頁’ 中有大量的空餘空間. (服務器會讀取大量不需要的數據, 浪費)
MyISAM 三種情況都會發生, InnoDB 不會出現短小的行碎片, 會將其合併到一個片段中.
* OPTIMIZE TABLE * 來優化表 , 不支持此命令的 存儲引擎可以 alter table t1 ENGINE=< engine >來操作.