[請益] 資料庫join後count速度問題

[stevekevin10 (hippo泡)]

抱歉又來請益個資料庫問題m_ _m
需要join 500萬 跟 3萬筆的表格
根據篩選條件後再根據後者的欄位做count
但現在下完query後都會卡住
請問該如何是好

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.136.97.130
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462697249.A.497.html
推 abc0922001: 弱弱問一下，資料庫有建立索引嗎
→ stevekevin10: 有
推 sivid: 能不能搬到cloud上面 scale up?
目前沒有cloud能用。。
※ 編輯: stevekevin10 (114.136.97.130), 05/08/2016 17:03:49
推 longlongint: 可以先用小筆測試資料來估計 500萬join3萬會是幾筆嗎
→ ga013077: 500萬的能先下條件縮小範圍??
推 andyjon: 該用hash join 看看
好 我試試看以前沒用過m_ _m
推 brucetu: 3萬筆的那張表 , 先篩過再來join?
是要join完後再篩@@
推 alog: 以前用過兩張數百萬筆的資料做join 結果性能悲劇
→ alog: 為了解決這個問題把整套db放到ram disk
→ alog: 結果還是跑了一整天沒有結果
→ alog: 調了db各種參數還是沒用
QQ
※ 編輯: stevekevin10 (114.136.97.130), 05/08/2016 17:41:11
→ alog: 後來我就異想天開 想說分批查詢試試 就把兩張表的資料用LIMI
→ alog: T 先控制住範圍
→ alog: 然後分幾次查詢 大概一次查詢只花了半分鐘
→ alog: 當天幹了要死XD
→ ian90911: 可以檢查是不是有開多線程搜尋?
推 gn01838335: Union不同條件的select
→ yyc1217: 可以用explain看看
→ yyc1217: 還是想看看query 也許會變成500萬*3萬個再篩選的結果
→ brucetu: 原本查詢長什麼樣子 為什麼一定要join完再篩@@
推 yourinfo: 問的太龍統了，簡單說就是先處理500萬，再join
→ yourinfo: 為什麼一定要先join才能查!?
推 sing10407: 太籠統了 sql貼出來才知道
推 et69523820: 我的作法是 都不join 單獨讀取出500萬放陣列 單獨讀取
→ et69523820: 3萬筆 放陣列  用key當元素 馬上就可以指到你要的資料
→ et69523820: 這樣總共讀取出503萬筆資料 大概幾分鐘就可以跑完
推 et69523820: join會有乘積效應 所以我基本上都不會用join都改用陣
→ et69523820: 列處理
推 kiwatami: 我猜你的資料庫啟動後沒有把資料讀到記憶體內
→ kiwatami: 而是用硬碟在跑才會這麼慢 然後你建的索引
→ kiwatami: 跟你 join 的欄位有一樣嗎
→ kiwatami: 把 schema 跟 SQL 都放上來比較好判斷
→ kiwatami: 500萬 * 3萬正常應該不至於會卡住
推 et69523820: 要看3萬對應出來有幾筆 如果對應出來有1000筆
→ et69523820: 500萬 * 1000筆 = 50億  2000筆就 100億...
→ alan3100: 大哉問 你這樣問從頭到尾都有東西可以講 等於沒講
推 abc0922001: 希望index的欄位有在查詢的欄位中XDD
推 sorianotw: 即便放到ram裡面，可以思考看看這樣的資源成本是否過
→ sorianotw: 高
→ sorianotw: 效能不是只有速度而已，資源耗用多少會影響整個系統的
→ sorianotw: 吞吐量，這也是需要去思考的議題
推 sorianotw: 蠻多使用join的情景，都可以拆分成數個simple select,
→ sorianotw:  資料量大的狀況下， 速度反而更快，且資源耗用量更小
推 kiwatami: 啟動時沒讀 搜尋後也是會存進去 只是先後順序而已
推 iamshiao: 推