把它当做另一个安全等级。您可以设计没有外键关系的表(完全有效)，并确保完全在业务层上存在关联实体。然而，外键被认为是很好的设计实践，因为它们增加了另一个约束级别，以防业务层出现问题。同样，字段大小限制和不使用varchar 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的更有效空间的方法。

遗留系统支持。如果您有一个正在使用数据的系统，并且希望数据有一定的长度，那么数据库是执行该长度的好地方。这并不理想，但遗留系统有时也不理想。= P

我的测试表明，在选择时存在差异。

CREATE TABLE t4000 (a NVARCHAR(4000) NULL);

CREATE TABLE tmax (a NVARCHAR(MAX) NULL);

DECLARE @abc4 NVARCHAR(4000) = N'ABC';

INSERT INTO t4000
SELECT TOP 1000000 @abc4
    FROM
    master.sys.all_columns ac1,
    master.sys.all_columns ac2;

DECLARE @abc NVARCHAR(MAX) = N'ABC';

INSERT INTO tmax
SELECT TOP 1000000 @abc
    FROM
    master.sys.all_columns ac1,
    master.sys.all_columns ac2;

SET STATISTICS TIME ON;
SET STATISTICS IO ON;

SELECT * FROM dbo.t4000;
SELECT * FROM dbo.tmax;

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

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.

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

1)当处理nvarchar(max) vs nvarchar(n)时，SQL服务器将不得不利用更多的资源(分配的内存和cpu时间)，其中n是一个特定于字段的数字。

2)就绩效而言，这意味着什么?

在SQL Server 2005上，我从一个有15个nvarchar(max)列的表中查询了13000行数据。 我重复计时查询，然后将列更改为nvarchar(255)或更小。

优化之前的查询平均为2.0858秒。更改后的查询平均返回时间为1.90秒。这比基本select *查询提高了约184毫秒。这一数字提高了8.8%。

3)我的结果与其他几篇文章一致，表明存在性能差异。根据数据库和查询的不同，改进的百分比可能有所不同。如果您没有很多并发用户或很多记录，那么性能差异对您来说不是问题。但是，随着记录和并发用户的增加，性能差异也会增加。