投影數量對查詢性能的影響

我期待改善從表格中選擇多個列的查詢的性能。想知道限制列的數量是否會影響查詢的性能。投影數量對查詢性能的影響

2010-02-03 Aadith

使用可變長度數據類型返回尾部列可能會導致搜索開銷 – 2010-02-03 18:52:50

限制列數對查詢沒有可衡量的影響。幾乎普遍地，整行被提取到緩存。該投影最後發生在SQL管道中。

處理的投影部分必須最後發生（例如在GROUP BY之後），因爲它可能涉及創建聚合。此外，JOIN，WHERE和ORDER BY處理可能需要許多列。結果集中最終返回的列數多於此值。在查詢計劃中添加一個步驟來執行預測以保存一些I/O是不值得的。

檢查您的查詢計劃文檔。查詢計劃中沒有「項目」節點。這是制定結果集的一小部分。

要擺脫「整行提取」，你必須去一個柱狀（「倒」）數據庫。

來源

2010-02-03 18:33:59

我認爲，減少列數對查詢速度的影響非常有限，但對數據傳輸速度的影響可能會更大。您選擇的數據越少，需要通過電匯傳輸到您的應用程序的數據就越少。

來源

2010-02-03 18:34:32 tvanfosson

我可能會被誤解的問題，但在這裏不用反正：

您選擇不產生巨大的變化列的絕對數量。但是，您選擇哪個列可以產生顯着差異，具體取決於表的索引方式。

如果您只選擇索引所涵蓋的列，那麼數據庫引擎可以只使用查詢的索引，而無需獲取表數據。如果你甚至使用一個沒有被覆蓋的列，但是它必須獲取整行（密鑰查找），這會顯着降低性能。有時候它會使性能如此之高以至於數據庫引擎選擇進行全面掃描，而不是對索引造成困擾;它取決於被選擇的行數。

因此，如果通過刪除列可以將其轉化爲覆蓋查詢，那麼可以提高性能。否則，可能不會。無論如何不明顯。

爲SQL Server 2005+

簡單的例子 - 假設這是你的表：

ID int NOT NULL IDENTITY PRIMARY KEY CLUSTERED, 
Name varchar(50) NOT NULL, 
Status tinyint NOT NULL

如果我們創建這個索引：

CREATE INDEX IX_MyTable 
ON MyTable (Name)

那麼這個查詢將會很快：

SELECT ID 
FROM MyTable 
WHERE Name = 'Aaron'

但是這個查詢會很慢（er）：

SELECT ID, Name, Status 
FROM MyTable 
WHERE Name = 'Aaron'

如果我們改變了索引覆蓋索引，即

CREATE INDEX IX_MyTable 
ON MyTable (Name) 
INCLUDE (Status)

然後第二個查詢快速再次成爲因爲DB引擎從未需要讀取的行。

來源

2010-02-03 18:38:44 Aaronaught

+1，用於顯示代碼並添加顯示INCLUDE如何工作的索引 – SQLMenace 2010-02-03 18:43:54

它可以依賴於你正在處理的服務器（以及在MySQL的情況下，存儲引擎）。舉例來說，至少有一個MySQL存儲引擎可以實現列式存儲而不是行式存儲，而在這種情況下，更多列可能需要更多時間。

另一個主要的可能性是，如果你已經分割你的表格，所以一些列存儲在一臺服務器上，而另一些列存儲在另一臺服務器上（又稱垂直分區）。在這種情況下，檢索更多列可能涉及從不同服務器檢索數據，並且負載總是可能不平衡，因此不同的服務器具有不同的響應時間。當然，你通常會盡量保持負載的合理平衡，這樣應該是非常不尋常的，但仍然有可能（尤其是，例如，如果其中一臺服務器處理了一些其他數據，其使用情況可能與其他數據無關）。

來源

2010-02-03 18:39:43

是的，如果你的查詢可以被非聚簇索引覆蓋，它將會更快，因爲所有的數據已經在索引和基表中（如果你有堆的話）或聚簇索引不需要被觸及優化器

來源

2010-02-03 18:42:45 SQLMenace

爲了演示tvanfosson已經寫入了什麼，有一個「傳輸」成本，我在查詢分析器的MSSQL 2000數據庫上運行以下兩條語句。

SELECT DATALENGTH（文本）從syscomments中

選擇文本從syscomments中

兩個結果返回947行，但第一個花了5臺和第二973毫秒。

此外，因爲字段是相同的，我不會指望在這裏索引。

來源

2010-02-03 19:28:19

投影數量對查詢性能的影響

回答

相關問題