對查詢最有效果的優化，自然是建立索引了，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萬，具體看客戶網路資料的分布情況，不好估計。
最後我和同事們對統計模式詳細分析，乙個同事提出再在預統計表基礎上進行二次預統計，我們估算了一下，基本上等使用者來查詢時，所面對的表已經很小了，最多幾千條記錄，很快了。解決統計查詢過程中，讓我體會到詳細分析業務流程細節，作出相應的優化，有時是可以解決問題的。
總體上來說，對資料庫查詢的優化，我們採取了一些常規的優化之後，如果還沒有取得想要的效果，我們有時候不必硬碰硬去優化查詢本身，改變一下使用模式，找找業務處理流程是否還有可修改的，說不定就輕鬆解決了存在的難題。還有就是主管要把整個開發組積極性調動起來，大家一起測試、分析、想辦法、驗證，最後一致確定乙個可行的方案，然後大家分頭去不打折扣的實現。
資料庫優化方案
1.sql 優化 2.索引 where 條件加索引 3.連線池 處理連線數問題，druid 4.快取 持久層快取 記憶體資料庫redis 5.分割槽 分成不同的檔案，不解決根本問題 6.儲存過程 業務 難維護 7.讀寫分離 主從複製 8.集群 與主從的區別 集群是通過負載均衡的方式，目的是容錯性和高...
資料庫優化方案
一 需要注意的點 1 對查詢進行優化，要盡量避免全表掃瞄 2 應盡量避免在 where 子句中對字段進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃瞄 3 不使用not in和 操作not in和 操作都不會使用索引將進行全表掃瞄。not in可以not exists代替，id 3則可...
資料庫優化方案
資料庫優化方案 慢日誌查詢 1.檢視慢查詢是否開啟 show variables like slow query show variables like long query time 2.開啟慢查詢 set global slow query log on 3.設定慢查詢日誌記錄檔案 set gl...