截至SQL Server 2019, NVARCHAR(MAX)仍然不支持SCSU“Unicode压缩”-即使使用行内数据存储存储。SCSU是在SQL Server 2008中添加的，适用于任何ROW/ page压缩的表和索引。

因此，即使没有存储在LOB中，具有相同文本内容的NVARCHAR(1..4000)字段所占用的物理磁盘空间也是NVARCHAR(1..4000)字段的两倍。非scsu浪费取决于所表示的数据和语言。

Unicode压缩实现:

SQL Server使用Unicode标准压缩方案(SCSU)算法的实现来压缩存储在行或页压缩对象中的Unicode值。对于这些压缩对象，对nchar(n)和nvarchar(n)列的Unicode压缩是自动的[并且从未对nvarchar(max)使用]。

另一方面，PAGE压缩(自2014年以来)仍然适用于NVARCHAR(MAX)列，如果它们被写入行内数据。所以缺乏SCSU感觉就像“缺少优化”。与SCSU不同，基于共享前导前缀(例如。重复的值)。

然而，使用NVARCHAR(MAX)可能仍然“更快”，即使使用OPENJSON这样的函数会有更高的IO成本，因为它避免了隐式转换。这是一种隐式转换开销，它取决于使用的相对成本，以及字段是在过滤之前还是过滤之后被处理的。在VARCHAR(MAX)列中使用2019年的UTF-8排序规则时也存在同样的转换问题。

使用NVARCHAR(1-4000)也需要N*2个字节的~8000字节行配额，而NVARCHAR(MAX)只需要24个字节。总体设计和使用需要一起考虑，以考虑具体的实现细节。

+在我的数据库/数据/模式中，通过使用两列(读时合并)，可以减少40%的磁盘空间使用，同时仍然支持溢出的文本值。SCSU虽然存在缺陷，但它是一种非常聪明且未得到充分利用的存储Unicode的更有效空间的方法。

我能看到的主要缺点是，假设你有这样的情况:

哪一个提供了关于UI所需数据的最多信息?

This

            CREATE TABLE [dbo].[BusData](
                [ID] [int] IDENTITY(1,1) NOT NULL,
                [RecordId] [nvarchar](MAX) NULL,
                [CompanyName] [nvarchar](MAX) NOT NULL,
                [FirstName] [nvarchar](MAX) NOT NULL,
                [LastName] [nvarchar](MAX) NOT NULL,
                [ADDRESS] [nvarchar](MAX) NOT NULL,
                [CITY] [nvarchar](MAX) NOT NULL,
                [County] [nvarchar](MAX) NOT NULL,
                [STATE] [nvarchar](MAX) NOT NULL,
                [ZIP] [nvarchar](MAX) NOT NULL,
                [PHONE] [nvarchar](MAX) NOT NULL,
                [COUNTRY] [nvarchar](MAX) NOT NULL,
                [NPA] [nvarchar](MAX) NULL,
                [NXX] [nvarchar](MAX) NULL,
                [XXXX] [nvarchar](MAX) NULL,
                [CurrentRecord] [nvarchar](MAX) NULL,
                [TotalCount] [nvarchar](MAX) NULL,
                [Status] [int] NOT NULL,
                [ChangeDate] [datetime] NOT NULL
            ) ON [PRIMARY]

还是这个?

            CREATE TABLE [dbo].[BusData](
                [ID] [int] IDENTITY(1,1) NOT NULL,
                [RecordId] [nvarchar](50) NULL,
                [CompanyName] [nvarchar](50) NOT NULL,
                [FirstName] [nvarchar](50) NOT NULL,
                [LastName] [nvarchar](50) NOT NULL,
                [ADDRESS] [nvarchar](50) NOT NULL,
                [CITY] [nvarchar](50) NOT NULL,
                [County] [nvarchar](50) NOT NULL,
                [STATE] [nvarchar](2) NOT NULL,
                [ZIP] [nvarchar](16) NOT NULL,
                [PHONE] [nvarchar](18) NOT NULL,
                [COUNTRY] [nvarchar](50) NOT NULL,
                [NPA] [nvarchar](3) NULL,
                [NXX] [nvarchar](3) NULL,
                [XXXX] [nvarchar](4) NULL,
                [CurrentRecord] [nvarchar](50) NULL,
                [TotalCount] [nvarchar](50) NULL,
                [Status] [int] NOT NULL,
                [ChangeDate] [datetime] NOT NULL
            ) ON [PRIMARY]

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

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

我发现的唯一问题是我们在SQL Server 2005上开发应用程序，在一个实例中，我们必须支持SQL Server 2000。我刚刚知道，SQL Server 2000不喜欢varchar或nvarchar的MAX选项。

截至SQL Server 2019, NVARCHAR(MAX)仍然不支持SCSU“Unicode压缩”-即使使用行内数据存储存储。SCSU是在SQL Server 2008中添加的，适用于任何ROW/ page压缩的表和索引。

因此，即使没有存储在LOB中，具有相同文本内容的NVARCHAR(1..4000)字段所占用的物理磁盘空间也是NVARCHAR(1..4000)字段的两倍。非scsu浪费取决于所表示的数据和语言。

Unicode压缩实现:

SQL Server使用Unicode标准压缩方案(SCSU)算法的实现来压缩存储在行或页压缩对象中的Unicode值。对于这些压缩对象，对nchar(n)和nvarchar(n)列的Unicode压缩是自动的[并且从未对nvarchar(max)使用]。

另一方面，PAGE压缩(自2014年以来)仍然适用于NVARCHAR(MAX)列，如果它们被写入行内数据。所以缺乏SCSU感觉就像“缺少优化”。与SCSU不同，基于共享前导前缀(例如。重复的值)。

然而，使用NVARCHAR(MAX)可能仍然“更快”，即使使用OPENJSON这样的函数会有更高的IO成本，因为它避免了隐式转换。这是一种隐式转换开销，它取决于使用的相对成本，以及字段是在过滤之前还是过滤之后被处理的。在VARCHAR(MAX)列中使用2019年的UTF-8排序规则时也存在同样的转换问题。

使用NVARCHAR(1-4000)也需要N*2个字节的~8000字节行配额，而NVARCHAR(MAX)只需要24个字节。总体设计和使用需要一起考虑，以考虑具体的实现细节。

+在我的数据库/数据/模式中，通过使用两列(读时合并)，可以减少40%的磁盘空间使用，同时仍然支持溢出的文本值。SCSU虽然存在缺陷，但它是一种非常聪明且未得到充分利用的存储Unicode的更有效空间的方法。

当你知道字段将在一个固定的范围内时，这不是一个好主意——例如5到10个字符。我想我只会在不确定长度的情况下使用max。例如，电话号码永远不会超过一定数量的字符。

你能诚实地说，你不确定表中每个字段的大约长度要求吗?

我确实明白你的意思——有些字段我肯定会考虑使用varchar(max)。

有趣的是，MSDN文档总结得很好:

的大小时使用varchar 列数据条目变化很大。 的大小时使用varchar(max) 列数据条目变化很大， 大小可能超过8000字节。

关于这个问题有一个有趣的讨论。