InnoDB
1、特性
具有較好的事務支持：支持4個事務隔離級別，支持多版本讀
行級鎖定：通過索引實現，全表掃描仍然會是表鎖，注意間隙鎖的影響
讀寫阻塞與事務隔離級別相關
具有非常高效的緩存特性：能緩存索引，也能緩存數據
整個表和主鍵以Cluster方式存儲，組成一顆平衡樹
所有Secondary Index都會保存主鍵信息
2、適用場景
需要事務支持（具有較好的事務特性）
行級鎖定對高并發有很好的適應能力，但需要確保查詢是通過索引完成
數據更新較為頻繁的場景
數據一致性要求較高
硬件設備內存較大，可以利用InnoDB較好的緩存能力來提高內存利用率，盡可能減少磁盤 IO
3、最佳實踐
主鍵盡可能小，避免給Secondary index帶來過大的空間負擔
避免全表掃描，因為會使用表鎖
盡可能緩存所有的索引和數據，提高響應速度
在大批量小插入的時候，盡量自己控制事務而不要使用autocommit自動提交
合理設置innodb_flush_log_at_trx_commit參數值，不要過度追求安全性
避免主鍵更新，因為這會帶來大量的數據移動
NDBCluster
1、特性
分布式：分布式存儲引擎，可以由多個NDBCluster存儲引擎組成集群分別存放整體數據的一部分
支持事務：和Innodb一樣，支持事務
可與mysqld不在一臺主機：可以和mysqld分開存在于獨立的主機上，然后通過網絡和mysqld通信交互
內存需求量巨大：新版本索引以及被索引的數據必須存放在內存中，老版本所有數據和索引必須存在與內存中
2、適用場景
具有非常高的并發需求
對單個請求的響應并不是非常的critical
查詢簡單，過濾條件較為固定，每次請求數據量較少，又不希望自己進行水平Sharding
3、最佳實踐
盡可能讓查詢簡單，避免數據的跨節點傳輸
盡可能滿足SQL節點的計算性能，大一點的集群SQL節點會明顯多余Data節點
在各節點之間盡可能使用萬兆網絡環境互聯，以減少數據在網絡層傳輸過程中的延時
注：以上三個存儲引擎是目前相對主流的存儲引擎，還有其他類似如：Memory，Merge，CSV，Archive等存儲引擎的使用場景都相對較少，這里就不一一分析了，如果有朋友感興趣，后面再補充吧。
由于各存儲引擎功能特性差異較大，這篇文章主要是介紹如何來選擇合適的存儲引擎來應對不同的業務場景。
系列的第五篇文章：MySQL數據庫性能優化之存儲引擎選擇
系列的第四篇文章：MySQL數據庫性能優化之SQL優化
系列的第三篇文章：MySQL數據庫性能優化之索引優化
系列的第二篇文章：MySQL 數據庫性能優化之表結構優化
系列的第一篇文章：MySQL 數據庫性能優化之緩存參數優化
MyISAM
1、特性
不支持事務：MyISAM存儲引擎不支持事務，所以對事務有要求的業務場景不能使用
表級鎖定：其鎖定機制是表級索引，這雖然可以讓鎖定的實現成本很小但是也同時大大降低了其并發性能
讀寫互相阻塞：不僅會在寫入的時候阻塞讀取，MyISAM還會在讀取的時候阻塞寫入，但讀本身并不會阻塞另外的讀
只會緩存索引：MyISAM可以通過key_buffer緩存以大大提高訪問性能減少磁盤IO，但是這個緩存區只會緩存索引，而不會緩存數據
2、適用場景
不需要事務支持（不支持）
并發相對較低（鎖定機制問題）
數據修改相對較少（阻塞問題）
以讀為主
數據一致性要求不是非常高
3、最佳實踐
盡量索引（緩存機制）
調整讀寫優先級，根據實際需求確保重要操作更優先
啟用延遲插入改善大批量寫入性能
盡量順序操作讓insert數據都寫入到尾部，減少阻塞
分解大的操作，降低單個操作的阻塞時間
降低并發數，某些高并發場景通過應用來進行排隊機制
對于相對靜態的數據，充分利用Query Cache可以極大的提高訪問效率
MyISAM的Count只有在全表掃描的時候特別高效，帶有其他條件的count都需要進行實際的數據訪問
InnoDB
1、特性
具有較好的事務支持：支持4個事務隔離級別，支持多版本讀
行級鎖定：通過索引實現，全表掃描仍然會是表鎖，注意間隙鎖的影響
讀寫阻塞與事務隔離級別相關
具有非常高效的緩存特性：能緩存索引，也能緩存數據
整個表和主鍵以Cluster方式存儲，組成一顆平衡樹
所有Secondary Index都會保存主鍵信息
2、適用場景
需要事務支持（具有較好的事務特性）
行級鎖定對高并發有很好的適應能力，但需要確保查詢是通過索引完成
數據更新較為頻繁的場景
數據一致性要求較高
硬件設備內存較大，可以利用InnoDB較好的緩存能力來提高內存利用率，盡可能減少磁盤 IO
3、最佳實踐
主鍵盡可能小，避免給Secondary index帶來過大的空間負擔
避免全表掃描，因為會使用表鎖
盡可能緩存所有的索引和數據，提高響應速度
在大批量小插入的時候，盡量自己控制事務而不要使用autocommit自動提交
合理設置innodb_flush_log_at_trx_commit參數值，不要過度追求安全性
避免主鍵更新，因為這會帶來大量的數據移動
NDBCluster
1、特性
分布式：分布式存儲引擎，可以由多個NDBCluster存儲引擎組成集群分別存放整體數據的一部分
支持事務：和Innodb一樣，支持事務
可與mysqld不在一臺主機：可以和mysqld分開存在于獨立的主機上，然后通過網絡和mysqld通信交互
內存需求量巨大：新版本索引以及被索引的數據必須存放在內存中，老版本所有數據和索引必須存在與內存中
2、適用場景
具有非常高的并發需求
對單個請求的響應并不是非常的critical
查詢簡單，過濾條件較為固定，每次請求數據量較少，又不希望自己進行水平Sharding
3、最佳實踐
盡可能讓查詢簡單，避免數據的跨節點傳輸
盡可能滿足SQL節點的計算性能，大一點的集群SQL節點會明顯多余Data節點
在各節點之間盡可能使用萬兆網絡環境互聯，以減少數據在網絡層傳輸過程中的延時
注：以上三個存儲引擎是目前相對主流的存儲引擎，還有其他類似如：Memory，Merge，CSV，Archive等存儲引擎的使用場景都相對較少，這里就不一一分析了，如果有朋友感興趣，后面再補充吧。