MySQL最佳化之——表策略和索引

本文試圖從資料表建立的策略（schema）和索引的角度描述最佳化選擇。

最佳化資料類型

1. 資料越小越好。選擇滿足需求的最小資料類型。通過節省更多的磁碟空間，記憶體以及cache，使得你的資料庫更快。
2. 選擇簡單的類型。整形值相比於字元型的代價較小，因為字元集和校對規則的關係。比如說應該儲存日期和時間，而不是個字串；IP地址也應該用數字儲存。
3. 儘可能的避免NULL。盡量把資料列定義為NOT NULL。可為NULL的列使得索引的實現更加複雜，查詢更難最佳化。

整型

      TINYINT  SMALLINT  MEDIUMINT  INT  BIGINT

  位元組  1              2                3              4       8

UNSIGNED屬性可以修飾以上類型，而像INT(11)後面的11隻是輸出顯示的位元，並不影響資料存放區和計算。

 

實數

FLOAT和DOUBLE是浮點型，分別佔4，8位元組。如果要儲存確切的數，需要DECIMAL類型。

DECIMAL類型以bit string的形式儲存。盡量用前者，因為DECIMAL消耗更多的儲存空間和計算時間。

 

字串類型

不同的儲存引擎對於CHAR和VARCHAR的實現是不同的。

VARCHAR：一般情況下VARCHAR只儲存所需的位元組空間，不過當MyISAM設定了FIXED 的ROW_FORMAT時例外。

                 VARCHAR在資料前用1~2位元組來儲存實際資料的長度。不過對於儲存所需長度方法，當資料更新空間不夠時會變得麻煩。

                 資料中的前置和後附的空格都存入和可讀出。

CHAR：     不儲存後面的空格。當儲存少量的字串或者資料長度較接近時，可以採用該類型。

 

盡量不使用BLOB和TEXT類型。

 

當值可以確定時，可用ENUM代替字串類型。

 

索引

1. 孤立WHERE位元組中的列。意思就是條件陳述式中要想用上index，則該列不能處於左邊的運算式中或函數中：如where id+1 = 5  。
2. 對於過長的列使用首碼索引