我們有一個大約有200,000條記錄的數據庫表。其中包含3個ntext列，其中包含長度從4000-70000不等的字符串數據。但僅僅在桌面上的選擇需要超過1分鐘才能返回數據。甚至使用where條件和索引來選擇12000條記錄，條件爲40秒。因此我們決定將這些數據類型更改爲nvarchar（max），但仍然沒有注意到主要區別，因爲它會將數據從行中存儲太長，因爲它太長了。有沒有更好的辦法可以改善我桌子的表現？SQL Server - 更好的數據類型來存儲大字符串值
您應該使列nvarchar而不是ntext，並且您可能將它們作爲非關鍵列包含在索引中。但是......這是你提取的很多數據。如果您需要頻繁執行查詢以便1分鐘的執行時間成爲問題，那麼也許您應該重新考慮您的方法。
你的第二個查詢，它可以傳送超過460千兆字節，這樣我就可以看到它採取的是長期潛在...
爲單記錄查詢，你可以嘗試分裂它成固定長度列：
即。第一部分的nchar（2000年），第2部分的nchar（4000），第三部分的nchar（8000），第4部分的nchar（16000）...
如果所有的cols是非變的，它更容易計算行邊界時的cols都固定長度。
如果你在查詢分析中顯示執行計劃，任何有用的顯示......？
井執行計劃顯示聚簇索引掃描100％，它只是一個選擇查詢與WHERE。最有趣的是它建議創建一個已經存在的索引。但它說也包括文本列，但SQL不允許在這些ntext列上創建索引 – Aneef 2010-01-22 09:02:24
什麼讓你覺得你的問題是你的現場數據類型？還有其他幾點需要考慮：
-yes我有索引 -我們能夠在我們的本地qa環境中重新創建此問題。所以帶寬不是問題。 -well執行計劃顯示聚簇索引掃描100％，它只是一個WHERE選擇查詢。最有趣的是它建議創建一個已經存在的索引。但它說也包括文本列，但SQL不允許在這些ntext列上創建索引 – Aneef 2010-01-22 09:06:03
您可以詳細討論該表結構，現有索引和where子句嗎？你在那裏使用任何函數？ – 2010-01-22 09:51:38
IMO在這裏的紅旗是他的聚集索引掃描，再加上返回集的大小。 – 2010-01-22 12:23:36
您不能將大文本字段移動到單獨的表格中，並將它們與1-1關係鏈接到主表格。這可能有助於加快速度
我同意凱文。任何掃描（聚集索引或其他）都是不好的，包括數據在內並不是一個實際的選擇。
將文本移動到具有自己主鍵的單獨表中，並將這三個字用作原始表中的外鍵。
我做了一些非常類似於這個存儲醫療索賠的文本數據，它的作品是一種享受。
（作爲一個附註）另外一個好處是，你不必在屏幕上同時顯示整個返回結果集的所有文本 - 所以你最終只能抓取您需要的特定文本數據。
這使您可以使用與摘要視圖（例如在stackoverflow上顯示問題列表）和作爲詳細視圖（顯示單個標題記錄的所有文本數據的位置）相同的表結構。
如果您不想將ntext列移動到另一個表中，請確保在最後一次傳遞前不檢索這些列。因此，而不是這樣的：
SELECT * FROM tbl WHERE (/* your code here*/)
嘗試這樣：
SELECT * FROM tbl WHERE id IN (SELECT id FROM tbl WHERE /* your code here */)
Gusy將表分區將提高速度呢？ – Aneef 2010-01-25 12:32:33