MySQL數據庫三種經常使用存儲引擎特性對比

轉自:http://www.jb51.net/article/77578.htm mysql

MySQL 的存儲引擎多是全部關係型數據庫產品中最具備特點的了,不只能夠同時使用多種存儲引擎,並且每種存儲引擎和MySQL之間使用插件方式這種很是鬆的耦合關係。sql

因爲各存儲引擎功能特性差別較大,這篇文章主要是介紹如何來選擇合適的存儲引擎來應對不一樣的業務場景。數據庫

MyISAM緩存

特性
不支持事務:MyISAM存儲引擎不支持事務,因此對事務有要求的業務場景不能使用
表級鎖定:其鎖定機制是表級索引,這雖然可讓鎖定的實現成本很小可是也同時大大下降了其併發性能
讀寫互相阻塞:不只會在寫入的時候阻塞讀取,MyISAM還會在讀取的時候阻塞寫入,但讀自己並不會阻塞另外的讀
只會緩存索引:MyISAM能夠經過key_buffer緩存以大大提升訪問性能減小磁盤IO,可是這個緩存區只會緩存索引,而不會緩存數據安全

適用場景
不須要事務支持(不支持)
併發相對較低(鎖定機制問題)
數據修改相對較少(阻塞問題)
以讀爲主
數據一致性要求不是很是高網絡

最佳實踐
儘可能索引(緩存機制)
調整讀寫優先級,根據實際需求確保重要操做更優先
啓用延遲插入改善大批量寫入性能
儘可能順序操做讓insert數據都寫入到尾部,減小阻塞
分解大的操做,下降單個操做的阻塞時間
下降併發數,某些高併發場景經過應用來進行排隊機制
對於相對靜態的數據,充分利用Query Cache能夠極大的提升訪問效率
MyISAM的Count只有在全表掃描的時候特別高效,帶有其餘條件的count都須要進行實際的數據訪問併發

InnoDB分佈式

特性
具備較好的事務支持:支持4個事務隔離級別,支持多版本讀
行級鎖定:經過索引實現,全表掃描仍然會是表鎖,注意間隙鎖的影響
讀寫阻塞與事務隔離級別相關
具備很是高效的緩存特性:能緩存索引,也能緩存數據
整個表和主鍵以Cluster方式存儲,組成一顆平衡樹
全部Secondary Index都會保存主鍵信息ide

適用場景
須要事務支持(具備較好的事務特性)
行級鎖定對高併發有很好的適應能力,但須要確保查詢是經過索引完成
數據更新較爲頻繁的場景
數據一致性要求較高
硬件設備內存較大,能夠利用InnoDB較好的緩存能力來提升內存利用率,儘量減小磁盤 IO高併發

最佳實踐
主鍵儘量小,避免給Secondary index帶來過大的空間負擔
避免全表掃描,由於會使用表鎖
儘量緩存全部的索引和數據,提升響應速度
在大批量小插入的時候,儘可能本身控制事務而不要使用autocommit自動提交
合理設置innodb_flush_log_at_trx_commit參數值,不要過分追求安全性
避免主鍵更新,由於這會帶來大量的數據移動

NDBCluster

特性
分佈式:分佈式存儲引擎,能夠由多個NDBCluster存儲引擎組成集羣分別存放總體數據的一部分
支持事務:和Innodb同樣,支持事務
可與mysqld不在一臺主機:能夠和mysqld分開存在於獨立的主機上,而後經過網絡和mysqld通訊交互
內存需求量巨大:新版本索引以及被索引的數據必須存放在內存中,老版本全部數據和索引必須存在與內存中

適用場景
具備很是高的併發需求
對單個請求的響應並非很是的critical
查詢簡單,過濾條件較爲固定,每次請求數據量較少,又不但願本身進行水平Sharding

最佳實踐儘量讓查詢簡單,避免數據的跨節點傳輸儘量知足SQL節點的計算性能,大一點的集羣SQL節點會明顯多餘Data節點在各節點之間儘量使用萬兆網絡環境互聯,以減小數據在網絡層傳輸過程當中的延時

相關文章
相關標籤/搜索