Schema的最佳化和索引

對於主鍵，選擇一個好的資料類型尤為關鍵。你可能經常需要用這些列和其他做比較以及用這些列尋找其他的列。你可能也把它們作為另一些表的外鍵。因此當你選擇主鍵的資料類型時，應該保持相關表主鍵類型一致。

當選擇主鍵的資料類型，你不僅要考慮儲存類型，也要考慮MySQL操作和比較這些類型的表現情況。比如，MySQL內部儲存ENUM和SET是作為整型的，但是當在字串環境下作比較的時候，MySQL會把它們轉為字串。

一旦你選擇了一個類型，要確定相關表都要使用這個類型。這個類型一定要精確，包括了它的屬性，如UNSIGNED。混合不同的資料類型，會引起效能問題。即使不會，在類型比較的時候，也會出現很難發現的錯誤。在忘記比較不同的資料類型之後，這些錯誤往往會發生。

根據你需要值的範圍，選擇最小的資料類型的範圍。並且要為以後留一些主鍵增長的空間。一個例子，你使用state_id來儲存美國州的名稱，你不需要上千或百萬的值。因此你不需要使用INT。一個TINYINT就足夠了並且它大小為3位元組。如果你使用它作為其他表的外鍵。三位元組就能發揮大的作用了。

Integer類型

Integer通常來說是主鍵類型的最佳選擇。因為它很快並且可以自增。

ENUM 以及SET

通常來說，雖然它們對於表中包含狀態或者類型值比較有用，但對於主鍵並不是一個好的選擇。ENUM和SET比較適合儲存一些如訂單的狀態，產品的類型，或者人的性別。

如果你使用了ENUM定義了一個產品的類型，你可能要根據唯一的ENUM欄位來尋找（你可能在這表中添加了產品的描述以及等等產品類型的相關資訊）。這種情況下你可能使用ENUM作為主鍵，但是大多數情況要避免使用。

String類型

如果可以，要儘可能避免使用String做為主鍵。它會浪費許多空間以及處理起來要慢於Integer。當使用MyISAM的表時，使用String要尤為小心。預設的情況下，MyISAM會對String類型的索引進行壓縮，這樣會使尋找變慢。

你也要小心使用隨機的String.如MD5(),SHA1(),UUID().隨機產生的String散列在大的空間中，這會降低插入和一些查詢語句的速度。

降低了INSERT語句，因為在索引中這插入的值會存入隨機的位置。這回造成頁的分割，隨機硬碟訪問，造成叢集索引片段。

降低SELECT速度，因為相鄰的行被分散在硬碟和記憶體中。

隨機值會導致緩衝能力的下降。因為它們消除了本地的引用。本地的引用是緩衝的工作方式。如果所有的資料都已經“預熱”了，把任意資料放到緩衝中沒有任何的優勢並且，如果工作資料集合沒有在記憶體中，緩衝就會有很多重新整理和尋找丟失的現象。

如果使用的UUID值，要去掉破折號或者使用UNHEX( )把UUID轉為16位元組的數並且，把它們存在BINARY(16)的列。你可使用HEX來獲得16進位的值。

UUID產生的值和其他雜湊函數如SHA1()產生的值有所不同。UUID的值分布不均並且稍微有點連續。但是它還是沒有整型好。