→ iFEELing:同一台實體機器可以切不同資源 如VM或LPAR 07/02 23:35
→ iFEELing:即使在同一個OS 也是有NICE之類的可以調 雖然效用嘛..... 07/02 23:35
→ Jack131:join真的是耗費很多資源 特別是很多個上百萬筆的一起 07/02 23:38
額外插個疑問。
小弟我不是 DBA ，對資料庫的觀念只有大學時代上過的一門資料庫管理系統概論
假設有兩個 Table A 和 B， Table A 有 N 筆紀錄，Table B 有 M 筆紀錄，
N 和 M 都是百萬以上。
假設我的條件只從 Table A 取 x 筆資料， Table B 取 y 筆資料。
x 和 y 都小於 100
也就是 Select * from A join B on ... where ...
資料庫到底會做出多少筆資料的 Join 呢？
(1) x * y
(2) N * M
(3) 其他
從我遙遠的記憶中，老師曾經教過 worst case 是 N * M，然後再用 where 條件
篩選。但那已經是十年前的課程內容
現在的商業資料庫真的還會做出 N * M 這種結果嗎?
推 ldkrsi:想知道+1 07/03 00:18
※ 編輯: mapleone 來自: 36.231.72.218 (07/03 00:23)
推 Ting1024:inner join 不會那麼瞎啦。你可以跑SQL看依下執行時間阿 07/03 00:37
推 avhacker:如果 join 的相關欄位沒 index, 應該會變 N + M 07/03 01:36
推 Adonisy:有索引很快的... 07/03 02:45
推 iceonly:mssql可以看實際執行計畫,其他不知不過應該也有吧? 07/03 07:21
→ mapleone:因為我們當 PG 的人通常沒有進入 DB 的權限，所以也看不 07/03 07:33
→ mapleone:到執行計畫。 07/03 07:33
※ 編輯: mapleone 來自: 111.248.3.242 (07/03 09:35)
推 iceonly:我們有測試用db,裡面是正式機某一時間的snapshot,所以可以 07/03 10:49
→ iceonly:試 07/03 10:49
推 mgtsai:有建索引的話，是 log N x log M，這麼大的資料本該建索引 07/03 10:55
推 mgtsai:寫錯.... 是 log N + x * log M @.@ 07/03 10:57
→ mgtsai:不過這要看 where 是否可以直接使用索引而定 07/03 10:59
→ felixgugu:所以要有反正規化設計，資料表拆的太多，就得一直join 07/03 11:59
→ felixgugu:當然index的建立與正確的使用where也很重要 07/03 11:59
推 cwlin0416:不管是不同一台機器，這樣做資源是可以靈活調動的，最 07/04 00:30
→ cwlin0416:後看瓶頸在那，就可以獨立硬體 07/04 00:30
推 cwlin0416:join 資料的使用是呈等比級數上升，當然盡量必免，一般 07/04 00:38
→ cwlin0416:人在使用比較不會去考慮，當然要限制，除非了解狀況的人 07/04 00:38
→ cwlin0416:，若在程式上做，做法比較靈活 07/04 00:38
推 sharpwolf:關聯式資料庫的話 worst case應該是N+M 07/04 01:20
→ sharpwolf:但是group by下錯語法會變成N*M的樣子 07/04 01:21