當表有很多列時SQL Server的性能

假設我有一個包含許多列的表格，例如30列，索引列爲1列。這個表格大約有30,000行。

如果我執行選擇其選擇索引列，和一個多個，例如這樣的：

SELECT IndexedColumn, column1 
FROM table

將這個比執行對僅具有2列的表相同的選擇，和做慢a SELECT * ...

所以基本上，如果我沒有從額外的列中檢索數據，額外列的存在是否會減慢select查詢事件？

來源

2017-08-02 Alex

如果'column1'不是你索引的一部分，'SELECT'沒有'WHERE'根本不會使用該索引。它必須使用聚簇索引，是的，掃描30列的聚簇索引比掃描2列中的一個要慢。這就是說 - 任何足夠強壯的服務器都會掃描30,000行任何可能忽略不計的時間，所以除非你每秒選擇幾次你不可能注意到的所有行。如果'column1' *是您的索引的一部分（即覆蓋），那麼聚集索引不會被命中，並且表中的列數是不相關的。考慮'INCLUDE'。 –

埃裏克Lippert寫了一個很好的[性能咆哮]（https://ericlippert.com/2012/12/17/performance-rant/） –

由於您不必爲最終客戶端（SSMS或其他應用程序）打印/傳遞其餘信息，因此在流程的最後階段會有細微的差異。

當執行基於聚簇索引的讀取時，所有列（無BLOB）都保存在同一頁面集中，以讀取數據，您必須訪問同一組頁面。

如果您在之後的列列表中有一個非聚簇索引，那麼它們將保存在它們自己的數據頁結構中（因此讀取的次數會更少），您會看到性能提高。

來源

2017-08-02 08:46:55

假設您在兩種情況下在表中定義主鍵時使用由SQL Server創建的默認集羣索引，則no，這兩種情況之間不應該有任何性能差異。也許值得檢查一下，並生成一個實際的執行計劃，看看自己？ - 實際上不確定上面是否爲真，因爲這是行存儲，第一個表不會在每個頁面上放入足夠多的行，所以在讀取數據時會遭受更多的IO /磁盤開銷。

來源

2017-08-02 08:13:53

當表有很多列時SQL Server的性能

回答

相關問題