目前有幾個查詢效率很低的SQL，不知道怎么優化，希望能得到一些幫助。
1.按時間分組查詢
select to_char(date, 'YYYY-MM-DD HH24) as d,count(*) as c from table group by d order by d
2.按時間統計
select count(*) from table where date between '12-5' and '12-6'
3.獲取某個條件的全部記錄
select a.col1,a.col2,a.col3,a.col4 from table a join (select col2,col3 from table where col1='123' and col4 between '12-5' and '12-6' group by col1,col2) b using(col1,col2) order by a.col2,a.col4
uj5u.com熱心網友回復：
第一個查詢，創建to_char函式索引試試，能否將表掃描轉移至只掃描索引；第二個查詢和第三個查詢，和資料分布有關系，如果where條件能過濾出少量記錄，那么可以創建條件欄位上的組合索引，第三個更復雜點的是有連接，如果table通過col1和col4過濾后的資料量很少，而且單個col1和col2欄位組合回傳資料量較少，在查詢2類似的優化上，還可以在連接欄位col1和col2上創建索引。
uj5u.com熱心網友回復：
第一個查詢的函式索引有個問題，函式索引的問題，我這個正好包含了時區，具體在這里：https://github.com/digoal/blog/blob/master/201206/20120626_02.md。用了date_trunc()在千萬級資料量也只是16s左右，達不到數量級的提升。第二個就只是按時間統計，時間欄位已經添加了索引，不過千萬級的資料量回應時間還是遠達不到要求。
第三個，首先符合這個條件的記錄是100多萬條。業務決定了必須一次性得到這個條件的記錄，再處理，不能分頁。col1和col4上已經建立了索引。col1和col2上資料量非常多，不過沒有索引。這個查詢是子查詢修改成的，雖然效率有所提升，還是達不到要求，目前時間大概是13s左右。
uj5u.com熱心網友回復：
如果你SQL最后回傳的資料量都在百萬，千萬量級，磁區才是你的選擇，而且十幾秒可以說你該滿足了uj5u.com熱心網友回復：
實際上我很懷疑這個10幾秒，沒有上百個節點的MPP，怕是完不成回傳千萬資料在10秒左右的這種壯舉。
uj5u.com熱心網友回復：
之前嘗試了按照每天進行了磁區，但每天資料量在2千萬到3千萬，查詢時間和不磁區差不多，并沒有明顯提升。剩下的就不知道怎么辦了uj5u.com熱心網友回復：
如果每天都這種資料量，還要統計，那其實應該用GP，不是用PG
uj5u.com熱心網友回復：
選擇pg主要是為了使用空間資料庫的功能，其他的不太符合要求，也不太熟悉。uj5u.com熱心網友回復：
GP是基于PG的，應該也支持的吧。
那么大量資料的統計，單機資料庫想快速計算出結果，不是不太可能，而是不可能啊
uj5u.com熱心網友回復：
說不可能可能太極端了，如果能上好點的存盤，比如nvme ssd，還是能提速的，但是想要長久保持穩定速度，磁區是少不了的。
uj5u.com熱心網友回復：
哦，硬體這塊就沒辦法了，只能在自己的范圍內盡量做了uj5u.com熱心網友回復：
1,試試建個to_char ( date, 'YYYY-MM-DD HH24' )函式索引，不過如果都愿意付出函式索引的代價了。還不如索性用觸發器和中間統計表，查詢性能會好很多 。2。第二個沒啥辦法，如果每天的資料量都很大的話，只能磁區表了，順便說一句beteen是個不好的習慣，每天第一個秒（或者毫秒納秒取決于data精度）會被重復計算，前閉后開的區間才是嚴謹合理的。
3.第三個沒看懂。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/16720.html
標籤：PostgreSQL
上一篇：請求優化下sql