上兩周一直想辦法提高查詢速度，取得一點效果，解決了部分問題，記下來以便將來自己檢視。
由於公司沒有專門的dba，我自己對mysql資料庫也不是很熟悉，而且這個j**a開發的網路審計系統的管理系統，是經過了n多人幾年時間的修修改改，今天到我們手裡，要改成能支援大流量情況的版本，所以對我們這個只有幾個人的j**a組來說，確實是個難題。
這個大流量的情況在以前的文章裡也提到過，就是要支援每秒鐘處理1g左右的網路資料報，http協議的資料報最多，因此http協議分析模組的流水日誌表記錄最大，據估算可能到達一天4000萬條記錄，採用一天一張表，那也是很大的，我看了.m檔案大小，已經是8g多了。
而我們管理系統查詢日誌記錄時，對好幾個欄位都要進行條件查詢，而且有幾個字段長度達到256，在8g這麼大的表裡查詢乙個字串，如果找不到，那必定程式設計客棧從頭要查到尾，速度慢得根本受不了。客戶還要好幾個字段一起設定條件來查詢，這樣基本上是二三十分鐘都出不來，系統可用性極差。
我採用的方法是以測試為主，同時看j**a**，通過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萬，具體看客戶網路資料的分布情況，不好估計。
最後我和同事們對統計模式詳細分析，乙個同事提出再在預統計表基礎上進行二次預統計，我們估算了一下，基本上等使用者來查詢時，所面對的表已經很小了，最多幾千條記錄，很快了。
解決統計查詢過程中，讓我體會到詳細分析業務流程細節，作出相應的優化，有時是可以解決問題的。
總體上來說，對資料庫查詢的優化，我們採取了一些常規的優化之後，如果還沒有取得想要的效果，我們有時候不必硬碰硬去優化查詢本身，改變一下使用模式，找找業務處理流程是否還有可修改的，說不定就輕鬆解決了存在的難題。
還有就是主管要把整個開發組積極性調動起來，大家一起測試、分析、想辦法、驗證，最後一致確定乙個可行的方案，然後大家分頭去不打折扣的實現。
**：liangbing 的部落格
本文標題: mysql資料庫查詢優化
本文位址: /news/exp/48094.html
mysql 資料庫查詢優化
合理選擇表字段型別型別 int型別優先於varchar型別 優先於text型別 varchar 變長字串 型別優先於char 不可變長 型別 表分割 對於頻繁使用的且資料量增長很快的表進行表的分割 水平分割 當一張表資料量非常大影響效率時，可將表中的資料按一定的演算法將其進行水平方向 行 的分割，如...
mysql 資料庫查詢優化
從上圖可以看出，計算機系統硬體效能從高到代依次為 cpu cache l1 l2 l3 記憶體 ssd硬碟 網路 硬碟 根據資料庫知識，我們可以列出每種硬體主要的工作內容 cpu及記憶體 快取資料訪問 比較 排序 事務檢測 sql解析 函式或邏輯運算 網路 結果資料傳輸 sql請求 遠端資料庫訪問 ...
mysql 查詢優化器 資料庫查詢優化器
所謂查詢優化，目標是關聯式資料庫下或者 newsql 的 sql server 層對 sql 語句進行優化，在不改變期望結果的情況下使得資料庫引擎計畫執行時間最短。狹義的查詢優化技術是指邏輯優化與物理優化 在後面會細講 廣義上的查詢優化技術包括從 sql 語句輸入開始，對 sql 語句的重寫，內部執...