MyISAM引擎和InnoDB引擎的特色

隨着MySQL的不斷更新，因爲各存儲引擎功能特性差別較大，這篇文章主要是介紹如何來選擇合適的存儲引擎來應對不一樣的業務場景，朋友們能夠根據業務需求，選擇合適的存儲引擎。^.^

• MyISAM
  • 特性
    1. 不支持事務：MyISAM存儲引擎不支持事務，因此對事務有要求的業務場景不能使用
    2. 表級鎖定：其鎖定機制是表級索引，這雖然可讓鎖定的實現成本很小可是也同時大大下降了其併發性能
    3. 讀寫互相阻塞：不只會在寫入的時候阻塞讀取，MyISAM還會在讀取的時候阻塞寫入，但讀自己並不會阻塞另外的讀
    4. 只會緩存索引：MyISAM能夠經過key_buffer緩存以大大提升訪問性能減小磁盤IO，可是這個緩存區只會緩存索引，而不會緩存數據
  • 適用場景
    1. 不須要事務支持（不支持）
    2. 併發相對較低（鎖定機制問題）
    3. 數據修改相對較少（阻塞問題）
    4. 以讀爲主
    5. 數據一致性要求不是很是高
  • 最佳實踐
    1. 儘可能索引（緩存機制）
    2. 調整讀寫優先級，根據實際需求確保重要操做更優先
    3. 啓用延遲插入改善大批量寫入性能
    4. 儘可能順序操做讓insert數據都寫入到尾部，減小阻塞
    5. 分解大的操做，下降單個操做的阻塞時間
    6. 下降併發數，某些高併發場景經過應用來進行排隊機制
    7. 對於相對靜態的數據，充分利用Query Cache能夠極大的提升訪問效率
    8. MyISAM的Count只有在全表掃描的時候特別高效，帶有其餘條件的count都須要進行實際的數據訪問
• InnoDB
  • 特性
    1. 具備較好的事務支持：支持4個事務隔離級別，支持多版本讀
    2. 行級鎖定：經過索引實現，全表掃描仍然會是表鎖，注意間隙鎖的影響
    3. 讀寫阻塞與事務隔離級別相關
    4. 具備很是高效的緩存特性：能緩存索引，也能緩存數據
    5. 整個表和主鍵以Cluster方式存儲，組成一顆平衡樹
    6. 全部Secondary Index都會保存主鍵信息
  • 適用場景
    1. 須要事務支持（具備較好的事務特性）
    2. 行級鎖定對高併發有很好的適應能力，但須要確保查詢是經過索引完成
    3. 數據更新較爲頻繁的場景
    4. 數據一致性要求較高
    5. 硬件設備內存較大，能夠利用InnoDB較好的緩存能力來提升內存利用率，儘量減小磁盤 IO
  • 最佳實踐
    1. 主鍵儘量小，避免給Secondary index帶來過大的空間負擔
    2. 避免全表掃描，由於會使用表鎖
    3. 儘量緩存全部的索引和數據，提升響應速度
    4. 在大批量小插入的時候，儘可能本身控制事務而不要使用autocommit自動提交
    5. 合理設置innodb_flush_log_at_trx_commit參數值，不要過分追求安全性
    6. 避免主鍵更新，由於這會帶來大量的數據移動
• NDBCluster
  • 特性
    1. 分佈式：分佈式存儲引擎，能夠由多個NDBCluster存儲引擎組成集羣分別存放總體數據的一部分
    2. 支持事務：和Innodb同樣，支持事務
    3. 可與mysqld不在一臺主機：能夠和mysqld分開存在於獨立的主機上，而後經過網絡和mysqld通訊交互
    4. 內存需求量巨大：新版本索引以及被索引的數據必須存放在內存中，老版本全部數據和索引必須存在與內存中
  • 適用場景
    1. 具備很是高的併發需求
    2. 對單個請求的響應並非很是的critical
    3. 查詢簡單，過濾條件較爲固定，每次請求數據量較少，又不但願本身進行水平Sharding
  • 最佳實踐
    1. 儘量讓查詢簡單，避免數據的跨節點傳輸
    2. 儘量知足SQL節點的計算性能，大一點的集羣SQL節點會明顯多餘Data節點
    3. 在各節點之間儘量使用萬兆網絡環境互聯，以減小數據在網絡層傳輸過程當中的延時