Re: [SQL ] JOIN TABLE時WHERE的用法會影響效能嗎?

看板Database (資料庫)作者 (夏天到了,冷不起來了說)時間8年前 (2016/06/23 20:57), 編輯推噓2(203)
留言5則, 1人參與, 最新討論串2/5 (看更多)

06/23 10:27,
1.JOIN能用inner就盡量不用left...JOIN內盡量避免使用
06/23 10:27

06/23 10:28,
子查詢 尤其又是資料筆數多的時候 另外JOIN內如真無可
06/23 10:28

06/23 10:29,
可避免要用到子查詢 建議增加欄位的限縮 有用的再挑出
06/23 10:29

06/23 10:29,
來 避免使用*
06/23 10:29

06/23 10:30,
2.WHERE條件內 string的查詢 避免使用like+or 可以改用
06/23 10:30

06/23 10:30,
union試試看
06/23 10:30

06/23 10:30,
3.開執行計畫看看是否有使用正確索引 耗用資源主要是在
06/23 10:30

06/23 10:31,
哪段語法上面 建立相對應的索引 A.key的部分也可以建
06/23 10:31

06/23 10:31,
立全文檢索試試看 這樣條件內可以嘗試使用全文檢索
06/23 10:31

06/23 10:33,
另外回答最後面的問題 兩個條件查詢的結果不會一樣
06/23 10:33

06/23 10:39,
上述為個人實務上處理經驗..有誤請再提出指教Orz
06/23 10:39

06/23 13:50,
都是Like '%%' 根本不會用索引
06/23 13:50
感謝streetbad版友的提醒 目前的寫法大致是如此, A資料庫有33萬比資料,B大約有10萬比。 兩個資料都有f1,f2這些欄位沒有建索引,經由key欄位關聯。 要搜尋A,B中f1或f2符合val值的資料 而且只顯示B最新的一筆 目前的寫法是如此,大概兩秒左右就能跑出資料了 不過上頭似乎還是覺得有點慢 XD 我用分析工具,有三個時間會比較慢 send data 0.29 sec send data 0.29 sec 猜測是要UNION兩個資料的sql send data 0.8 sec 然後這把匯集的資料再SELECT這一段 這種情形應該常見不是很罕見, 猜想應該還會有更好的方法,只是一時還想不太出來啊。 SELECT W.* FROM ( SELECT W.*,O.* FROM W LEFT JOIN ( SELECT Key,f1,f2,f3 FROM ( SELECT Key,f1,f2,f3 FROM O WHERE O.Key <> '' AND (O.f1='val' OR O.f2='val') ) as O Order by O.f3 desc limit 1 ) as O ON W.key = O.key WHERE W.key <> '' AND (W.f1='val' OR W.f2='val') UNION SELECT W.*,O.* FROM W LEFT JOIN ( SELECT Key,f1,f2,f3 FROM ( SELECT key,f1,f2,f3 FROM O WHERE O.key <> '' AND (O.f1='val' OR O.f2='val') ) as O Order by O.f3 desc limit 1 ) as O ON W.key = O.key WHERE W.key <> '' AND (O.f1='val' OR O.f2='val') ) as W -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.255.152.9 ※ 文章網址: https://www.ptt.cc/bbs/Database/M.1466686672.A.A6F.html

06/24 00:10, , 1F
如不介意是可釋出一點欄位內容資訊及條件還有欲產出的
06/24 00:10, 1F

06/24 00:10, , 2F
結果比較方便提供協助
06/24 00:10, 2F

06/24 00:13, , 3F
另外多層SELECT的動作還有LEFT JOIN子查詢的部份 可以
06/24 00:13, 3F

06/24 00:13, , 4F
朝先塞到temp table的方向 字串的條件看起來也是可再
06/24 00:13, 4F

06/24 00:13, , 5F
調整 目前應該主要是這三塊在拖速度
06/24 00:13, 5F
文章代碼(AID): #1NQzpGfl (Database)
討論串 (同標題文章)
文章代碼(AID): #1NQzpGfl (Database)