我有一個大的非規格化表格，它反映了每年加載的固定長度平面文件的組成。 112列和400,000條記錄。在構成對此表最常見的查詢的where子句的3列上有唯一的聚集索引。索引碎片是.01。查詢的性能很好，次秒。但是，返回所有記錄需要將近2分鐘。執行計劃顯示100％的成本是在集羣索引掃描（不尋求）。大規模非規範化表格優化
有沒有查詢需要加入（由於denorm）。該表用於報告。所有字段都是nvarchar類型（數據文件中字段的長度）。
超出正常化表格。我還能做些什麼來提高性能。
嘗試分頁查詢。您可以將結果拆分成100行組。這樣，你的用戶會很快看到結果。另外，如果他們每次查看結果時都不需要查看所有數據，則會大大減少檢索的數據量。
除此之外，向查詢過濾數據的參數將減少返回的數據量。
這篇文章是開始使用分頁的好辦法：SQL Pagination Query with order by
只需更換「50」和「100」的答案，使用頁面的變量，你是好去。
這裏有三個想法。首先，如果你不需要nvarchar，把它們切換到varchar。這將使存儲需求減半，並且應該讓事情變得更快。
其次，確保字段的長度小於nvarchar（4000）/ varchar（8000）。任何更大的值都會將值存儲在單獨的頁面上，從而延長檢索時間。
第三，你不說你是如何檢索數據。如果您將它帶回另一個工具（如Excel或ODBC），則可能存在其他性能瓶頸。最後，雖然您正在檢索大量的數據，所以您應該預計時間會比檢索少數幾行的時間長得多。
當您詢問所有行時，您將始終進行掃描。
400,000行X 112列X每列17字節是761,600,000字節。 （我抽出17個空氣。）花兩分鐘時間在網絡上移動3/4的演出並不錯。這大致是我的服務器計劃備份到磁盤的吞吐量。
你有更快的網絡資金嗎？
表中有多少數據（字節）？你有什麼樣的網絡連接？ 2分鐘對於大量數據聽起來是合理的。 – Oded 2012-03-02 17:10:07
它正在執行掃描，因爲您正在返回所有記錄......所以沒有理由進行尋找。就像@Oded所說的那樣，你的表現將基於你的網絡......除非你簡單地找到一種方式來返回更少的數據，那將是你的瓶頸。 – 2012-03-02 18:18:52