列數是否會“減慢” SQL 連接所需的時間？

我正在使用 R 程式語言執行以下 SQL 查詢來執行內部聯接：

table_1 = data.frame(id = c("123", "123", "125", "125"), id2 = c("11", "12", "14", "13"),
date_1 = c("2010-01-31","2010-01-31", "2015-01-31", "2018-01-31" ))

table_1$id = as.factor(table_1$id)
table_1$id2 = as.factor(table_1$id2)
table_1$date_1 = as.factor(table_1$date_1)

table_2 = data.frame(id = c("123", "123", "125", "125"), id2 = c("111", "112", "14", "113"),
date_2 = c("2009-01-31","2010-01-31", "2010-01-31", "2010-01-31" ),
date_3 = c("2011-01-31","2010-01-31", "2020-01-31", "2020-01-31" ))


table_2$id = as.factor(table_2$id)
table_2$id2 = as.factor(table_2$id2)
table_2$date_2 = as.factor(table_2$date_2)
table_2$date_3 = as.factor(table_2$date_3)

#SQL

library(sqldf)

sqldf("select distinct * 
 from table_1 a inner join table_2 b
 on (a.date_1 between b.date_2 and b.date_3) and 
    a.id = b.id or (a.id2 = b.id2)")

**我的問題：**在我的實際數據中，“table_1”和“table_2”各包含大約 20 列 - 但是，“連接”不需要這些列中的大多數。如果我包括所有這些列（例如 select * from table_1 vs. select id, date_1 from table_1） - 這會使“加入”需要更長的時間嗎？或者電腦是否忽略了“加入”中不需要的其他列，並且無論是否包含所有列與僅包含所需列，都只需花費相同的時間？

謝謝！

老實說，這取決於表上存在的索引。例如，如果 SQL 能夠執行索引查找，並且索引包含所需的列，它可以停在那裡並將結果連接在一起。在這種情況下，包含任意數量的列不會真正改變查詢的持續時間。

但是，創建覆蓋所有列的 NONCLUSTERED 索引並不常見。在這種情況下，SQL 需要對連接進行索引搜尋，然後使用 Key Lookup 來檢索所有列。這會增加查詢的持續時間。

希望這可以幫助。

不，它不應該（在大多數情況下）必然影響JOIN操作本身的性能，但是……**是的，它減慢了 query 的總執行時間，**原因如下：

1. 更多的列需要更多的數據：從磁碟定位，從磁碟讀取並可能寫入記憶體，最後從記憶體讀取並返回到消費客戶端（可能通過網路）。這些資源中的每一個都有局限性，尤其是磁碟 I/O 通常是最大的瓶頸。
2. 不需要的列可以消除可能使用最有效的查詢計劃，從而以最有效的方式為您的查詢提供數據。這是因為被請求的額外列可能不是您查詢的最佳索引的一部分，從而導致要使用聚集索引（或其他行 ID）。
3. 與原因 #2 類似，可以選擇效率較低的索引操作，例如使用鍵查找進行掃描或查找，以定位不必要的附加列的數據。
4. 等待請求的資源（例如記憶體授予）的時間超過必要的時間可能會對性能產生額外的影響，因為需要更多的資源來為您不需要的其他列的數據提供服務。

SELECT *是一個非常糟糕的反模式/不好的做法，您可以在這個 StackOverflow 問題中閱讀其他原因（除了我前面提到的幾點）。

引用自：https://dba.stackexchange.com/questions/303439