使用 MAX 文本或更具體、更小的類型

有人正在審查我的 DDL 程式碼以創建表格並建議，當他們看到我看到使用VARCHAR(256)文本欄位時，我希望非常小，比如名字或其他什麼，我應該總是使用VARCHAR(MAX)和連結為什麼使用任何東西，而不是 varchar(max ) . 我讀了它，但它似乎過時了，因為它專注於 2005 年，並​​且似乎沒有提供任何真正的理由來為所有文本欄位每行分配高達 2 GB 的空間。

從性能、儲存等角度來看，應該如何決定是使用VARCHAR(MAX)SQL Server 的現代版本還是使用更小更具體的類型？（例如，2008 年、2012 年、2014 年）

我應該總是使用(n)varchar(max)文本列嗎？

不。

對於 SQL Server，max只有在別無選擇時才應指定數據類型。相反，應該選擇正確的基本類型 (varchar或nvarchar) 並指定適合要儲存的數據的顯式最大長度。

無論列的類型是varchar(n)還是，物理儲存都是相同的varchar(max)，所以這不是問題。

不在任何地方選擇的原因(n)varchar(max)都圍繞著功能、計劃質量和性能。

詳盡的列表可能不實用，但除其他外，max列：

特徵

• 需要單獨的約束來強制執行最大長度
• 不能是索引中的鍵（因此也沒有唯一約束）
• 可能會阻止線上 DDL（包括索引重建和添加新的非空列）
• 通常不支持“較新”功能，例如列儲存
• 有關更具體的功能和限制，請參閱產品文件。max一般模式是圍繞數據類型存在尷尬的限制和限制。並非所有限制和副作用都記錄在案。

表現

• 需要在執行引擎中進行特殊處理，以解決可能非常大的大小。通常，這涉及使用效率較低的程式碼路徑和流介面
• 可能對外部程式碼（以及 SSIS 等其他 SQL Server 組件）產生類似的意外後果，這些程式碼還必須準備好處理高達 2GB 的數據
• 在記憶體授予計算中假定為 4000 字節寬。這很可能導致過多的記憶體預留，從而限制並發性，並將有價值的索引和數據頁推出記憶體記憶體
• 禁用幾個重要的性能優化
• 可能會延長鎖定持續時間
• 可能會阻止優化器選擇（非動態）搜尋計劃
• 防止過濾器被推入掃描並作為殘留物尋找
• 可能會增加 tempdb 壓力和爭用（取決於版本），因為變數和參數也可能被鍵入max以匹配列定義

---

總而言之，不必要地使用說明符會產生許多微妙的（和不受歡迎的）副作用max，因此這樣做沒有任何意義。使用單一聲明的輕微“便利”並不是一種補償。

在上下文中評估每種類型，使用正確的基本類型（varchar或nvarchar）和合理的顯式長度。

進一步閱讀：

• Remus Rusanu的 varchar(max) 與 varchar(n) 的性能比較
• 閱讀Craig Freedman 的Committed 和 Large Objects
• tempdb 的容量規劃
• 刪除分頁和轉發的幽靈（我）

引用自：https://dba.stackexchange.com/questions/140790