程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MYSQL入門知識 >> Mysql引擎選擇參考

Mysql引擎選擇參考

編輯:MYSQL入門知識
Mysql 應該選擇什麼引擎

  對於如何選擇存儲引擎,可以簡答的歸納為一句話:“除非需要用到某些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.

  

 

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved