首頁 培訓計劃 培訓課程 企業內訓 學員論壇 技術文章 成功案例 師資簡介 關于我們 在線留言  
行業新聞
MySql數據庫查詢優化

文章來源:http://www.kuqin.com/database/20090614/56692.html 作者: 發布日期:2009-12-25
打 印】【關 閉

上兩周一直想辦法提高查詢速度,取得一點效果,解決了部分問題,記下來以便將來自己查看。

由于公司沒有專門的DBA,我自己對mysql數據庫也不是很熟悉,而且這個JAVA開發的網絡審計系統的管理系統,是經過了N多人幾年時間的修修改改,今天到我們手里,要改成能支持大流量情況的版本,所以對我們這個只有幾個人的JAVA組來說,確實是個難題。

這個大流量的情況在以前的文章里也提到過,就是要支持每秒鐘處理1G左右的網絡數據包,HTTP協議的數據包最多,因此HTTP協議分析模塊的流水日志表記錄最大,據估算可能到達一天4000萬條記錄,采用一天一張表,那也是很大的,我看了.MYD文件大小,已經是8G多了。

而我們管理系統查詢日志記錄時,對好幾個字段都要進行條件查詢,而且有幾個字段長度達到256,在8G這么大的表里查詢一個字符串,如果找不到,那必定從頭要查到尾,速度慢得根本受不了??蛻暨€要好幾個字段一起設置條件來查詢,這樣基本上是二三十分鐘都出不來,系統可用性極差。

我采用的方法是以測試為主,同時看JAVA代碼,通過Log4j和Perf4j日志,看每個sql語句使用的時間,尋找性能瓶頸,然后有的放矢地進行優化。

對查詢最有效果的優化,自然是建立索引了,ID自然是自增、主鍵,這個前人已經做了;從where語句分析,時間字段作為查詢條件很多,時間是8字節,而且不重復,設置索引比較適合。我把時間設置為索引,有一點效果,但不大,估算一下:8 * 4000 0000 = 320 000 000 字節,4000萬記錄的表僅僅時間一個字段的索引將是320M,這還僅僅是我們上百張表的一張表而已(客戶要求我們至少保存3個月記錄)。

建立索引能起到一定作用,但還是解決不了我們的問題。物理表建立不能再縮短時間了,因為一天一張表,3個月就91~92張表,30個協議模塊就得2700多,這僅僅是協議流水日志表,還有其它表呢。

也不能把客戶要求做成條件的字段都設置成索引,那索引表將和原表差不多大,索引就失去意義了。在數據庫本身上優化,想去想來實在一下子想不到好辦法,感覺數據量大了,就算在Oracle上也沒有什么神奇辦法吧。

我最后采用分段查詢的方法,就是4000萬條數據,我不管你設置什么條件來查詢,我都是平均劃為成N段來查詢,比如400萬為一段,在頁面上提供一個下拉單:0~400萬,400~800萬,...,3600~4000萬,雖然查詢比較麻煩一點,但每段查詢的速度大大提高,控制在30秒左右,犧牲一些可用性,總比30分鐘還查不出來好吧。

流水日志可以采用分段查詢解決,但客戶要求的各種統計呢,這不能說分段統計,別人要統計2天的,你分開是不行的。

以前已經采用了一次預統計,預先定時在后臺對流水日志表進行統計一次,保存到預統計表,等用戶來查詢時,從預統計表進行各種查詢----這個做法好,不得不夸下前任開發人員。

但現在形勢不同了,因為預統計表是采用一個月一張的,就現在流水日志表的規模,那預統計表可能一張表超過4000萬,具體看客戶網絡數據的分布情況,不好估計。

最后我和同事們對統計模式詳細分析,一個同事提出再在預統計表基礎上進行二次預統計,我們估算了一下,基本上等用戶來查詢時,所面對的表已經很小了,最多幾千條記錄,很快了。

解決統計查詢過程中,讓我體會到詳細分析業務流程細節,作出相應的優化,有時是可以解決問題的。

總體上來說,對數據庫查詢的優化,我們采取了一些常規的優化之后,如果還沒有取得想要的效果,我們有時候不必硬碰硬去優化查詢本身,改變一下使用模式,找找業務處理流程是否還有可修改的,說不定就輕松解決了存在的難題。

還有就是主管要把整個開發組積極性調動起來,大家一起測試、分析、想辦法、驗證,最后一致確定一個可行的方案,然后大家分頭去不打折扣的實現。

本文來自:http://www.cppblog.com/cool-liangbing/archive/2009/06/14/87665.html

打 印】【關 閉

上一篇:如何學習.NET
下一篇:FriendFeed實現基于MySQL的無模式存儲
相關新聞
版權所有©威課網 粵ICP備13058727號