一个缺点是，您将围绕一个不可预知的变量进行设计，您可能会忽略而不是利用内部SQL Server数据结构，逐步由Row(s)、Page(s)和Extent(s)组成。

这让我想到了C中的数据结构对齐，并且通常认为知道对齐是一件好事(TM)。相似的想法，不同的背景。

页面和区段的MSDN页面

行溢出数据的MSDN页面

我检查了一些文章，并从http://www.sqlservercentral.com/Forums/Topic1480639-1292-1.aspx找到了有用的测试脚本 然后将其更改为NVARCHAR(10) vs NVARCHAR(4000) vs NVARCHAR(MAX)之间的比较，我在使用指定的数字时没有发现速度差异，但在使用MAX时。你可以自己测试。希望这有帮助。

SET NOCOUNT ON;

--===== Test Variable Assignment 1,000,000 times using NVARCHAR(10)
DECLARE @SomeString NVARCHAR(10),
        @StartTime DATETIME;
--=====         
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='10', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO
--===== Test Variable Assignment 1,000,000 times using NVARCHAR(4000)
DECLARE @SomeString NVARCHAR(4000),
        @StartTime DATETIME;
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='4000', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO
--===== Test Variable Assignment 1,000,000 times using NVARCHAR(MAX)
DECLARE @SomeString NVARCHAR(MAX),
        @StartTime DATETIME;
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='MAX', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO

起初我是这么想的，但后来又想了想。这样做会影响性能，但同样地，它也可以作为一种文档形式来了解字段的实际大小。当数据库位于更大的生态系统中时，它确实会强制执行。在我看来，关键是要在合理的范围内宽容。

ok, here's my feelings simply on the issue of business and data layer logic. It depends, if your DB is a shared resource between systems that share business logic then of course it seems a natural place to enforce such logic, but its not the BEST way to do it, the BEST way is to provide an API, this allows the interaction to be tested and keeps business logic where it belongs, it keeps systems decoupled, it keeps your tiers within a system decoupled. If however your database is supposed to be serving only one application, then lets get AGILE in thinking, what's true now? design for now. If and when such access is needed, provide an API to that data.

显然，这只是理想情况，如果您正在使用现有系统，那么您可能需要至少在短期内以不同的方式进行操作。

有时您希望数据类型对其中的数据强制执行一些意义。

例如，你有一列不应该超过20个字符。如果您将该列定义为VARCHAR(MAX)，一些恶意应用程序可能会向其中插入一个长字符串，而您永远不会知道，或者没有任何方法来阻止它。

下次应用程序使用该字符串时，假设字符串的长度对于它所代表的领域来说是适度和合理的，那么您将体验到一个不可预测和令人困惑的结果。

如果一行中的所有数据(对于所有列)不会合理地占用8000或更少的字符，那么数据层的设计应该强制执行这一点。

数据库引擎可以更有效地将所有内容排除在blob存储之外。限制行越小越好。一页中可以塞进的行越多越好。当数据库必须访问更少的页面时，它的性能会更好。

根据已接受的答案中提供的链接，似乎是:

存储在nvarchar(MAX)字段中的100个字符将与存储在nvarchar(100)字段中的100个字符没有区别-数据将内联存储，并且您不会有“行外”读取和写入数据的开销。所以不用担心。 如果大小大于4000，数据将自动“行外”存储，这是你想要的。所以也不用担心。

然而……

不能在nvarchar(MAX)列上创建索引。可以使用全文索引，但不能在列上创建索引以提高查询性能。对我来说，这就决定了……总是使用nvarchar(MAX)是一个明显的缺点。

结论:

如果你想要一种贯穿整个数据库的“通用字符串长度”，它可以被索引，并且不会浪费空间和访问时间，那么你可以使用nvarchar(4000)。