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