Schema的最佳化和索引

這一章的結束，我們來說一下關於設計模型的儲存引擎的選擇，這些你應該牢記。我們不會全面的介紹儲存引擎，目標就是列出一些影響資料模型設計的一些關鍵性因素。

MyISAM儲存引擎

表鎖（Table locks）

MyISAM是表一級的鎖。小心地是這個不會成為一個瓶頸。

沒有自動資料恢複（No automated data recovery）

如果MySQL伺服器掛了或者電源關閉。你應該在使用表之前來修複MyISAM表。如果有個大表，這個過程可能會持續幾個小時。

不支援事物（No transactions）

MyISAM不支援事物。事實上，MyISAM表不能保證一個單獨的語句會執行完成。如果一個錯誤發生在多個UPDATE之中，一些行被更新而另外的行並不會更新。

只有索引會被緩衝（Only indexes are cached in memory）

在MySQL進程內部，關鍵的緩衝區中，MyISAM只會緩衝索引。作業系統緩衝了表的資料，因此在MySQL5.0中，要想擷取資料，就需要作業系統的調用。這個過程消耗是較大的。

壓縮儲存（Compact storage）

每一行都是緊挨著的，因此需要的硬碟就會小並且全表掃描就會很快。

Memory儲存引擎

表鎖（Table locks）

像MyISAM表一樣，Memory表支援表鎖。這不是個問題，因為語句都是在記憶體中執行的。非常快。

沒有動態行（No dynamic rows）

Memory表不支援動態（比如，變數的長度）行，因此它們不支援BLOB,TEXT欄位。一個VARCHAR(5000)轉為CHAR(5000)-如果大部分資料都是小的話，就會浪費大量記憶體。

Hash索引是預設的索引類型（Hash indexes are the default index type）

不像其他的儲存引擎，它的預設索引類型是hash。

沒有索引統計（No index statistics）

Memory表不支援索引統計，因此可能對於複雜的查詢，執行很不理想。

重啟動後內容丟失（Content is lost on restart）

Memory不會持久化任何資料。因此伺服器重啟後，資料都會丟失，但表還是存在的。

InnoDB儲存引擎

事物（Transactional）

InnoDB支援事物，並且支援4個層級的事物隔離等級。

外鍵（Foreign keys）

MySQL5.0，InnoDB是唯一支援外鍵的儲存引擎。其他儲存引擎在CREATE TABLE時可以建立外鍵，但是不會約束。一些第三方引擎，比如solidDB以及PBXT，在儲存引擎層級支援它們。MySQL AB準備在伺服器層級支援外鍵。