nvarchar（4000）的性能影響？

Question

我有一個聲明爲nvarchar（4000）的列，4000是SQL Server對nvarchar長度的限制。它不會被用作排序行的關鍵。

在將nvarchar字段的長度設置爲4000之前，是否有任何暗示需要注意？

更新

我存儲的XML，一個XML序列化對象要準確。我知道這並不好，但我們很可能永遠都不需要對它進行查詢，這個實現大大縮短了我們打算擴展的某些功能的開發時間。我希望XML數據的平均長度爲1500個字符，但可能會有這樣的例外，它可能超過4000個字符。它可能超過4000個字符嗎？如果它發生的話，它可能會在非常罕見的情況下發生。這個應用程序任務至關重要不，不是。

Answer 1

你肯定需要nvarchar，或者你可以去與varchar？該限制主要適用於SQL Server 2k。你在使用2k5/2k8嗎？

Answer 2

SQL Server有三種類型的存儲：行內LOB和行溢出，請參閱Table and Index Organization。行內存儲是訪問速度最快的。 LOB和Row-Overflow彼此相似，都比行中稍慢。

如果您有一列NVARCHAR（4000），它將被存儲在行中（如果可能），如果不存在，它將存儲在行溢出存儲中。擁有這樣一個列並不意味着未來的性能問題，但它引發了一個問題：爲什麼nvarchar（4000）？您的數據可能總是接近4000個字符？它可以是4001，在這種情況下你的應用程序將如何處理它？爲什麼不用nvarchar（max）？你是否測量過性能，發現nvarchar（max）對你來說太慢了？

我的建議是要麼使用一個小的nvarchar長度，適合真實的數據，要麼nvarchar（max）如果預計很大。 nvarchar（4000）聞起來像不合理，未經過測試的過早優化。

更新

對於XML，使用XML data type。它比varchar或nvarchar具有許多優點，例如它支持XML indexes，它支持XML methods，並且可以實際驗證XML是否符合特定模式或至少符合格式良好的XML合規性。

XML將存儲在行外的LOB存儲中。

即使數據不是XML，我仍會推薦長度爲1500的LOB存儲（nvarchar（max））。與檢索LOB存儲數據相關的成本，但成本超過通過將表縮小爲來補償。表格行的寬度是性能的主要因素，因爲更寬的表格適合每頁更少的行，所以任何必須掃描一行或整個表格的操作都需要將更多頁面存取到內存中，並且這會顯示在查詢成本（實際上是,驅動因素的總成本）。一個LOB存儲的列只擴展了行的大小，如果我沒有記錯的話，這個行的寬度是'page id'，如果我沒有記錯的話，這個寬度是8個字節，所以你可以得到每頁更好的行密度，因此查詢速度更快。

Answer 3

你確定你確實需要多達4000個字符嗎？如果1000是實際的上限，爲什麼不把它設置爲？相反，如果你可能得到超過4000字節，你會想看看nvarchar（max）。

我喜歡「鼓勵」用戶不太自由地使用存儲空間。存儲給定行所需的空間越多，每頁可以存儲的空間就越少，這可能會在讀取或寫入表時導致更多的磁盤I/O。即使只需要存儲很多字節的數據（即不是每行全部4000個字節），只要獲得超過2000個字符的nvarchar數據，每頁只有一行，性能可以真正遭受。

這當然假設你需要存儲unicode（雙字節）數據，並且每行只有一個這樣的列。如果你不這樣做，請下降到varchar。