對於如何選擇存儲引擎，可以簡答的歸納為一句話：“除非需要用到某些INNODB 不具備的特性，並且沒有其他辦法可以替代，否則都應該選擇INNODB 引擎”。例如：如果要用到全文索引，建議優先考慮INNODB加上Sphinx的組合，而不是使用支持全文索引的myisam。當然，如果不需要用到InnoDB的特性，同時其他引擎的特性能夠更好的滿足需求，也可以考慮一下其他存儲引擎。舉個例子，如果不在乎可擴展能力和並發能力，也不在乎崩潰後的數據丟失問題，卻對InnoDB的空間占用比較敏感，這種場合下選擇MyISAM就比較合適。
除非萬不得已，否則建議不要混合使用多種存儲引擎，否則可能帶來一系列負責的問題，以及一些潛在的bug和邊界問題。存儲引擎層和服務器層的交互已經比較復雜，更不用說混合多個存儲引擎了。至少，混合存儲引擎對一致性備份和服務器參數配置都帶來了一定的困難。
如果應用需要不同的存儲引擎，請先考慮以下幾個因素：
事務
如果應用中需要事務支持，那麼InnoDB（或者XtraDB）是目前最穩定，並且經驗證的選擇。如果不需要事務，並且主要是SELECT 和 INSERT 操作，那麼myisam是不錯的選擇。一般日志型的應用比較符合這一特性。
備份
備份的需求也會影響到存儲引擎的選擇。如果可以定期的關閉服務器來執行備份，那麼備份的因素可以忽略。反之，如果需要在線熱備份，那麼選擇InnoDB就是基本的要求。
崩潰恢復
數據量比較大的時候，系統崩潰後如何快速的恢復是一個需要考慮的問題。相對而言，Myisam 崩潰後發生損壞的概論比INNODB 要高很多，而且恢復速度也很慢。因此，即使不需要事務支持，很多人也選擇INNODB 引擎，這也是一個非常重要的因素。
特有的特性
最後，有些應用可能依賴一些存儲引擎獨有的特性或者優化，比如很多應用依賴聚簇索引的優化。另外mysql 中也只有myisam 支持地理空間搜索。如果一個存儲引擎擁有一些關鍵的特性，同時又缺乏一些必要的特性，那麼有時候不得不做折中的考慮，或者在架構設計上做一些取捨。某些存儲引擎無法直接支持的特性，有時候通過變通也可以滿足需求。
你不需要現在就做決定，本系列接下來會提供很多關於各種存儲引擎優缺點的詳細描述，也會討論一些架構設計的技巧。一般來說，可能有很多選項你還沒有意識到，等閱讀完本系列回頭再看這些問題可能有些幫助。如果無法確定，那麼就使用InnoDB ，這個默認選擇是最安全的，尤其是搞不清楚具體要什麼的時候。
日志型應用如何選擇引擎
假如你需要實時地記錄一台中心電話交換機的每一通電話日志到mysql中，或者通過Apache的mod_log_sql 模塊將網站的所有訪問信息直接記錄到表中。這一類應用的插入速度有很高的要求，數據庫不能成為瓶頸，MYISAM或者Archive存儲引擎對這類應用比較適合，因為他們成本開銷低，而且插入速度非常快。
如果需要對記錄的日志做分析報表，則事情就會變得有趣 了。生成報表的sql很有可能會導致插入效率降低，這時候怎麼辦？
一種解決方法：是利用mysql內置的復制方案將數據復制一份到備份庫，然後在備份庫執行比較好事和cpu的查詢。這樣主庫只用於高效的插入工作，而備份庫上執行的查詢也無需擔心影響到日志的插入性能。當然也可以在系統負載較低的時候執行報表查詢操作，但是應用在不斷變化，如果依賴這個策略可能以後會導致問題。
另外一種方法： 在日志記錄表的名字中包含年月的信息，比如web_logs_2015_11或者web_logs_2015_jan。這樣可以在已經沒有插入操作的歷史表上做頻繁的查詢操作，而不會干擾到最新的當前表上的插入操作。
只讀或者大部分情況下只讀的表
有些表的數據用於編制類目或者分裂清單（如工作崗位，競拍，不動產等）這些應用場景是典型的讀多寫少的業務。如果不介意MyISAM 的崩潰恢復問題，選擇MyISAM 引擎是合適的。不過不要低估崩潰恢復問題的重要性，有些存儲引擎不會保證將數據安全的寫入磁盤中，而許多用戶實際上並不清楚這樣有多大的風險（MyISAM 只將數據寫到內存中，然後等待操作系統定期的將數據刷出到磁盤上）。
tips：一個值得推薦的方式，是在心梗測試環境模擬真實環境，運行應用，然後拔下電源模擬崩潰測試。對崩潰恢復的第一手測試經驗是無價之寶，可以避免真的崩潰時手足無措。
不要輕易相信 ‘MYISAM 比 INNODB 快’之類的經驗之談，這個結論往往不是絕對的。在很多我們已知的場景中，INNODB 的數度都可以讓MYISAM 望塵莫及，尤其是用到聚簇索引，或者需要訪問的數據都可以放入內存的應用。在後面的章節，讀者可以了解更多影響存儲引擎性能的因素（如數據大小，io請求量，主鍵還是二級索引等）以及這些因素對應用的影響。
當設計上述類型的應用時，建議蠶蛹InnoDB 。MyISAM 引擎在一開始可能沒有任何問題，但是隨著應用壓力的上升，則可能迅速惡化。各種鎖征用、崩潰後的數據丟失問題都會隨之而來。
訂單處理
如果設計訂單處理，那麼支持事務就必須選擇。半完成的訂單無法吸引應用的用戶。另外一個重要的考慮點是存儲引擎對外鍵的支持情況。InnoDB 是訂單處理類應用的最佳選擇。
電子公告牌和主題討論論壇
對於mysql 的用戶，主題討論區是個很有意思的話題。當前有成百上千的基於php或者perl的免費系統可以支持主題討論。其中大部分的數據庫操作效率都不高，因為他們大多傾向於在一次請求中執行盡可能多的查詢語句。另外還有部分系統設計為不采用數據庫，當然也就無法利用到數據庫提供的一些方便特性。主題討論區一般都有更新計數器，並且為給個主題計算訪問統計信息。多數應用只設計了幾張表來保存所有的數據，所以核心表的讀寫壓力可能非常大。為保證這些核心表的數據一致性，鎖成為資源競爭的主要因素。
盡管有這些設計缺陷，但大多數應用在低負載時可以工作的很好。如果web站點的規模迅速擴展，流量隨之猛增，則數據庫訪問可能變得非常慢。此時一個典型的解決方案是更改為支持更高讀寫的存儲引擎，但有時用戶會發現這麼做反而導致系統變得更慢了。
用戶可能沒有意識到這是由於某些特殊的查詢的緣故，典型的如：
SELECT COUNT(*) FROM table
問題在於，不是所有的存儲引擎運行上述查詢都非常快：對於MYISAM 確實會非常快，但其他的可能不行。每種引擎都能找出類似和對自己有利的例子。下一章將幫助用戶分析這些情況，演示如何發現和解決存在的這類問題。
CD-ROM應用
如果要發布一個基於CD-ROM或者DVD-ROM並且使用mysql數據文件的應用，可以考慮使用MYISAM或者MYISAM壓縮表，這樣表之間可以隔離，兵器可以在不同介質上相互拷貝。MYISAM壓縮表比未壓縮表要節約很多空間，但壓縮表是只讀的。在某些應用中這可能是很大的問題。但如果數據放到只讀戒指的場景下，壓縮表的只讀特性就不是問題了，這就沒有理由不使用壓縮表了。
大數據量
什麼樣的數據量算大？我們創建或者管理很多INNODB 數據庫的數據量在3-5tb之間，或者更大，這是單台機器上的量，而不是一個分片（shard）的量。這些系統運行得還不錯，要做到這一點需要合理的選擇硬件，做好物理設計，並為服務器的io瓶頸做好規劃。在這樣的數據量下，如果采用myisam，崩潰後的恢復就是一個噩夢。
如果數據量持續增長到10tb以上級別，可能就要建立數據倉庫。Infobright，是myslq數據倉庫最成功的解決方案。也有一些大數據庫不適合Infobright，卻可能適合TokuDB.
