MySQL是一個(gè)小型關(guān)系型數據庫管理系統,開(kāi)發(fā)者為瑞典MySQL AB公司。在2008年1月16號被Sun公司收購。而2009年,SUN又被Oracle收購.對于Mysql的前途,沒(méi)有任何人抱樂(lè )觀(guān)的態(tài)度.目前MySQL被廣泛地應用在Inte.net上的中小型網(wǎng)站中。由于其體積小、速度快、總體擁有成本低,尤其是開(kāi)放源碼這一特點(diǎn),許多中小型網(wǎng)站為了降低網(wǎng)站總體擁有成本而選擇了MySQL作為網(wǎng)站數據庫。
假如你想要用MysQL來(lái)實(shí)時(shí)記錄從呼叫中心的電話(huà)來(lái)的每一個(gè)電話(huà)的日志記錄;蛘吣憧赡芤呀(jīng)為Apache安裝了mod_log_sql模塊,這樣你就可以將網(wǎng)站所有的訪(fǎng)問(wèn)記錄到數據庫中。在這樣的一個(gè)應用中,速度可能是最重要的目標,你不想要數據庫成為瓶頸。MyISAM和Archive存儲引擎將會(huì )是很好的選擇,因為它們只有很低的開(kāi)銷(xiāo)并且可以一秒鐘插入成千上萬(wàn)條記錄。PBXT存儲引擎也可能特別適合這個(gè)目的。
然而,如果你決定對已經(jīng)記錄的數據進(jìn)行分析總結,那么事情就開(kāi)始變得有趣了。根據你所使用的查詢(xún)的不同,有很大的可能性因為數據采集的影響而使得整個(gè)插入過(guò)程變慢。這個(gè)時(shí)候你應該怎么辦?
一個(gè)解決方案是利用MySQL的內置復制特性來(lái)將數據克隆到第二臺服務(wù)器(從機)上,然后在從機上運行對于對于時(shí)間和CPU要求比較高的查詢(xún)。這使得主機只是插入操作,并且可以使你在從機上運行任何你需要的查詢(xún)而不必擔心對日志實(shí)時(shí)性的影響。
你也可以將查詢(xún)分成開(kāi)銷(xiāo)很小的查詢(xún)來(lái)完成任務(wù),但是不要指望這個(gè)策略能一直有效,因為你的程序的規模一直在增長(cháng)。
另外的一個(gè)選擇是使用Merge表。Merge表不會(huì )總是將日志記錄到同一個(gè)表,可以通過(guò)調整應用使得日志按照需求記錄到按年、月、日分表的表中去,比如web_log_2009_01或者web_log_2009_01_01。然后定義一個(gè)Merge表,它包含了你想要進(jìn)行綜合分析的數據。如果你需要分析一天或者一周的數據,那么這個(gè)策略可以直接使用,而你只需要創(chuàng )建分得更細的表,比如web_logs_2008_01_01。你的應用將日志插入到一張表中,而你而在其他的表上進(jìn)行查詢(xún)。
只讀或者很少寫(xiě)的表
包含用于創(chuàng )建目錄或者列出某類(lèi)數據(如職業(yè)、標售、財產(chǎn)等)的表通常讀要遠大于寫(xiě)操作的次數。這使得它們成為MyISAM表的首要客戶(hù),當然前提是你不在乎當MyISAM崩潰之后的故障恢復的話(huà)。不要低估這個(gè)問(wèn)題,很多用戶(hù)其實(shí)對于一個(gè)不認真嘗試將數據寫(xiě)入硬盤(pán)的存儲引擎所帶來(lái)的風(fēng)險并不是很清楚。
注:一個(gè)很好的想法是在一臺測試服務(wù)器上運行一個(gè)實(shí)際負載的模擬,然后去撥掉電源插銷(xiāo)。從故障中恢復數據的第一手經(jīng)驗是無(wú)價(jià)。它可以能夠輕松應對后面遇到的許多很令人頭痛的問(wèn)題。
不要只是單純的相信“MyISAM比InnoDB快”的經(jīng)驗。它并不是無(wú)條件的正確的。我們可以舉出很多InnoDB遠比MyISAM快的例子,尤其是對于那些使用簇索引或者數據正好在內存中的應用來(lái)說(shuō)。當你讀過(guò)本書(shū)的其他部分之后,你就會(huì )對于影響存儲引擎性能的因素有一個(gè)比較清楚的認識(數據量、IO率、主鍵vs次主鍵等等),這樣子你才能夠對哪些因素對于你的應用有影響有清楚的理解。
訂單處理
當你處理不管何種類(lèi)型的訂單處理時(shí),事務(wù)都是不可或缺的。半完成狀態(tài)的訂單不可能使你的客戶(hù)喜歡你所提供的服務(wù)。另外一個(gè)很重要的因素是存儲引擎是否支持外鍵約束。在這本書(shū)完成之時(shí),InnoDB似乎還是你最好的選擇,但是其他的事務(wù)型存儲引擎也可以作為一個(gè)候選者。
股票報價(jià)
如果你正在為個(gè)人分析而收集股票報價(jià)的話(huà),一般來(lái)說(shuō),MyISAM將會(huì )工作地很好。但是,如果你正在運行一個(gè)流量很大的web service,它有實(shí)時(shí)的報價(jià)反饋并且有成千上萬(wàn)的用戶(hù)的話(huà),查詢(xún)不能有等待。許多客戶(hù)可能同時(shí)都想往同一張表里插入數據或者讀取數據,因此行級別的鎖或者一種可以減少更新的策略都是可選擇的解決方案。
BBS的論壇
針對主題的討論對于MySQL的用戶(hù)來(lái)說(shuō)是一個(gè)很有趣的問(wèn)題。有許多免費的基于PHP和Perl的系統都可以提供針對主題的討論。其中許多應用并沒(méi)有考慮數據庫效率問(wèn)題,因此它們一般都會(huì )對一個(gè)請求查詢(xún)多次數據庫。有一些應用是不針對具體數據庫的,因此它們并沒(méi)有使用任何數據庫的特性來(lái)提升性能。它們會(huì )針對多個(gè)主題來(lái)更新計數器,收集使用統計等。有些應用甚至采用單表來(lái)存儲它們所有的數據。事實(shí)上造成的結果是,少部分中心表成為讀寫(xiě)操作的重心,而用來(lái)保證一致性的鎖成為造成競爭的基本來(lái)源。
如果不考慮設計上的缺陷的話(huà),這些系統多數都是為了中小型負載而設計的。然而,如果一個(gè)網(wǎng)站增長(cháng)得很大,并且流量也很可觀(guān)時(shí),它很可能就會(huì )變得很慢了。一個(gè)顯而易見(jiàn)的解決方案是換用另外一種可以處理大量讀寫(xiě)操作的存儲引擎,但是試圖這么做的用戶(hù)往往會(huì )驚訝地發(fā)現他們的系統甚至比沒(méi)有轉換之前更慢。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/