表變量列中的nvarchar（max）與nvarchar（n）

Question

在最終向用戶呈現結果集之前，我對表變量做了很多工作。 例如，我可能從許多不同的表中拉入一大堆列，如下所示：

DECLARE @tmp TABLE
(
ID int,
username nvarchar(50),  -- data taken from tbl_Users
site nvarchar(50),      -- data taken from tbl_Sites
region nvarchar(100),   -- data taken from tbl_Regions
currency nvarchar(5)    -- data taken from tbl_Currencies
)

我花了很多時間瀏覽對象資源管理器以確保列的數據長度正確（與原始表匹配）。 有時，如果我更改表模式但不更新所有過程，我可能會遇到截斷錯誤。

采取懶惰的做法是否有任何問題：

DECLARE @tmp TABLE
(
ID int,
username nvarchar(max),
site nvarchar(max),
region nvarchar(max),
currency nvarchar(max)
)

nvarchar(max)實際上是否會占用更多內存，或者這是基於數據大小分配的內存？ 還有其他陷阱嗎？

請注意，我知道跳轉到定義的第三方工具，但這不是我要求的。

UPDATE

重復的問題有價值，但問題不一樣恕我直言。 副本圍繞實際表的設計而不是表變量 。 但是，答案中有一些優點，即：

• nvarchar（max）vs nvarchar（8000）在資源使用方面沒有差異，直到8000+數據長度
• 業務邏輯層依賴於結構和有意義的數據，因此指定與原始值相稱的列大小可提供值

從這個意義上說，在表變量中使用nvarchar(max)而不是nvarchar(n)似乎沒問題，但在某些環境中它具有可靠性和性能風險。 如果你認為這應該被刪除然后公平（但請停止爭論我欣賞所有輸入！）

Answer 1

我想不出任何理由nvarchar（max）在一個表變量中會有任何與在表中使用nvarchar（max）不同的陷阱（ 在這個問題中解釋其缺點 ），除了陷阱由於表變量和臨時/永久表之間的差異（例如，可怕的統計數據，沒有二級索引等）。 Martin Smith在這里對表變量和臨時表進行了很好的比較 。

您仍然需要擔心某些問題，例如，如果您使用古典技術（如經典ASP / ADO），您可能會發現必須最后列出MAX列以確保結果准確。 我在2000年之前解釋了這一點，然后才引入MAX類型 ; 但是他們在TEXT / NTEXT舊提供商中遇到了同樣的問題。 你不太可能使用這種技術，但我想我會提到它以防萬一。

不過，我建議你在編寫代碼時只需要點擊並編寫正確的類型。 它們很容易從元數據派生（例如sys.columns或右鍵單擊表並將腳本稱為>創建到>剪貼板），這樣做可以防止出現任何問題（例如上面提到的關於不匹配長度的@JC。 ）可能導致溢出/截斷）。

另外，正如我之前暗示的那樣，如果你有大量的行（感謝@Stuart），你應該考慮使用#temp表。 我仍然認為無論你選擇什么都應該明確。 在這種情況下，將MAX用於所有事情的唯一好處是它可以讓你變得懶惰，同時為你帶來很大的風險。 您編寫一次代碼，但是您的用戶無數次地運行它。 花費額外的幾分鍾來使您的數據類型正確，即使這意味着如果架構發生更改，您必須稍后更正兩次。

至於nvarchar(max)的內存使用情況，是的，這可能會改變你的性能。 有關證據，請參閱此博客文章 。 部分相關片段，我的拼寫/語法更正：

因此，如果您確定nvarchar列的長度小於8000，則不要將列定義為nvarchar（max），而是盡可能將其定義為nvarchar（fixedlength）。 我看到使用固定長度的主要優點是：

內存授權可能是服務器已經缺乏內存的一個大問題。 正如預期的行大小更多，優化器將估計更多的內存授予，這個值將遠遠高於實際需要，這將浪費像內存一樣寶貴的資源。 如果您有幾個使用nvarchar（max）列的查詢並且需要排序，則服務器可能存在與內存相關的問題。 這可能是一個很大的問題。

他列出的其他優勢與索引有關。 無論如何，表變量都不是問題，因為您無法創建二級索引（在SQL Server 2014之前）。

但是再一次，無論你從哪個類型的表結構中提取數據，這個潛在的問題都沒有什么不同 - 臨時表，表變量，永久表等。