在SQL Server 2005中,将所有字符字段设置为nvarchar(MAX)而不是显式指定长度(例如nvarchar(255))有什么缺点吗?(除了不能在数据库级别限制字段长度之外)


当前回答

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

其他回答

同样的问题也出现在MSDN论坛上:

Varchar(max) vs Varchar(255)

原文(更多信息):

When you store data to a VARCHAR(N) column, the values are physically stored in the same way. But when you store it to a VARCHAR(MAX) column, behind the screen the data is handled as a TEXT value. So there is some additional processing needed when dealing with a VARCHAR(MAX) value. (only if the size exceeds 8000) VARCHAR(MAX) or NVARCHAR(MAX) is considered as a 'large value type'. Large value types are usually stored 'out of row'. It means that the data row will have a pointer to another location where the 'large value' is stored...

数据库的任务是存储数据,以供企业使用。让数据有用的一部分是确保它是有意义的。允许用户为自己的名字输入无限个字符并不能确保数据有意义。

将这些约束构建到业务层是一个好主意,但这并不能确保数据库保持完整。保证数据规则不被违反的唯一方法是在数据库中尽可能低的级别执行它们。

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

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

页面和区段的MSDN页面

行溢出数据的MSDN页面

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

这将导致性能问题,尽管如果数据库较小,可能永远不会导致任何实际问题。每条记录将占用硬盘驱动器上更多的空间,如果您一次搜索大量记录,数据库将需要读取更多的磁盘扇区。例如,一个小的记录可以适合50个扇区,而一个大的记录可以适合5个扇区。如果使用大记录,则需要从磁盘读取10倍的数据。