這是我的困境。在表中使用VARCHAR（MAX）有缺點嗎？
基本上，我需要一個表中的列來保存未知長度的字符。但我很好奇，如果在Sql Server中使用VARCHAR（MAX）或NVARCHAR（MAX）可能會出現性能問題，例如：'這次'我只需要存儲3個字符，大部分時間我只需要存儲10個字符。但是有一個小小的機會，可能會達到該專欄中的幾千個字符，甚至可能是一百萬個，這是不可預測的。但是，我可以保證它不會超過2GB的限制。
我只是好奇，如果有任何性能問題，或可能更好的方法來解決這個問題。
對我來說聽起來像你打算使用varchar（MAX）數據類型來實現其預期目的。
當MAX數據類型的數據超過8 KB時，將使用溢出頁面。 SQL Server 2005自動爲頁面分配一個溢出指示符，並知道如何操作數據行，就像操縱其他數據類型一樣。
如要進一步瞭解，請查看聯機叢書：char and varchar
沒有，VARCHAR（最大值）的調整本身基於錄入的大小，所以它是最有效的，如果你會使用各式各樣的大小的輸入。
我剛剛在前幾天看到this這篇文章。它在varchar（n）列上記錄了varchar（max）相當小的性能滯後。可能不足以讓你有所作爲。但如果是這樣，也許可以使用單獨的表來存儲這些少量的大文本塊。你的小文本可以留在主表中，但你可以添加一個標誌字段來告訴你在新表中查找大表。
您不能在varchar(max)（和nvarchar(max)）列上創建索引（儘管它們可以包含在它們中，但是誰會在索引中包含一列可能會達到2GB ?!），所以如果要搜索此值，除非使用全文索引，否則每次都會執行一次掃描。另外，請記住，任何報告設計師或演示設計師（網絡或其他）都必須假定有人可能會將百科全書放入該專欄並圍繞它進行設計。沒有什麼比聽到「用戶可能不會做X」更糟糕。如果用戶可以做到，他們就會做到。如果一個用戶可以將一個tome放入一個列，他們會在某個時間點。如果他們從未這麼做，那麼國際海事組織（IMO）將柱尺寸限制在一定的合理水平是更有意義的，並且如果用戶試圖將更多東西填充到允許的列中，則會引發關於它們是否應該將該值輸入的討論該列在第一位。
查看時的「Lob Data」頁面類型我強烈反對。根據我的經驗，用戶經常會出現違反任意大小限制的情況。 OTOH，我從來沒有看到有人將整個百科全書複製到表單中。 – dan04 2010-05-08 01:04:36
@ dan04 - IME，開發人員通常不會花時間來獲取關於列的實際意圖的規範。設置沒有限制的問題是，用戶把垃圾放入列中，因爲他們可以然後抱怨他們的報告被取消，或者屏幕加載速度緩慢，或者他們將FirstName LastName放入單個字段，現在他們無法按最後一個排序名稱等等，所以你需要停止你正在做的事情並修復他們的數據。沒有一定的限制，沒有任何東西可以表明，直到爲時已晚，某人試圖將某些東西塞進一個不應該在那裏的列中。 – Thomas 2010-05-08 02:06:02
問題是，有些人*實際上有40個字母的多連字姓，並且當你嘗試將其強制爲一個VARCHAR（16）時發出抱怨。 – dan04 2010-05-08 21:02:54
我見過一些問題 - 特別是對於標量函數（但是這些通常很糟糕，無論如何）返回varchar（MAX），然後不重新投射。例如，假設你有一個特殊的函數CleanString（somevarcharmax）返回varchar（max）並在varchar（50）上調用它，但不要CAST（CleanString（varchar10col）AS varchar（10）） - 討厭的性能問題。
但是，通常情況下，當您在表中使用varchar（max）列時，您不應該一次性執行這些類型的操作，所以我會說如果您正確使用它以滿足表中的數據需求，那很好。
Crystal Reports 12（以及其他版本，據我所知）沒有正確處理varchar（max），並將其解釋爲varchar（255），這會導致報表中的截斷數據。
所以，如果你使用水晶報表，這是varchar（max）的缺點。或者使用Crystal的缺點，確切地說。
參見：
http://www.crystalreportsbook.com/Forum/forum_posts.asp?TID=5843&PID=17503
http://michaeltbeeitprof.blogspot.com/2010/05/crystal-xi-and-varcharmax-aka-memo.html
雖然完全正確，我會避免使用術語溢出，因爲行溢出是爲VARCHAR（n）的頁面類型名稱，而VARCHAR（最大）去到使用DBCC Ind。 – Andrew 2010-04-04 19:33:45