varchar(MAX)总是比较好?

关于SQL Server,我明白:

那么,当使用varchar ,最好使用MAX ,因为我们不会分配整个大小?

我们是否应该使用一个常量大小,只有当我们想在这个数据库列上强制执行时才有这个限制?

4 Solutions collect form web for “varchar(MAX)总是比较好?”

SO User @Remus Rusanu在这个主题上有一篇很好的文章。 这里有一个我偷了的小窍门,但是我build议你读一下:

处理MAXtypes(varchar,nvarchar和varbinary)的代码path与处理其等价的非最大长度types的代码path不同。 非最大types可以在内部表示为一个普通的指针和长度结构。 但最大types不能作为一个连续的内存区域内部存储,因为它们可能长到2Gb。 所以他们必须用stream式接口来表示,类似于COM的IStream。 这延续到涉及最大types的每个操作,包括简单的赋值和比较,因为这些操作在stream接口上更复杂。 在分配和分配最大typesvariables(我的第一个testing)的代码中可以看到最大的影响,但是每个操作的影响都是可见的。

在文章中,他展示了几个例子,certificate使用varchar(n)通常会提高性能。

你可以在这里find整篇文章。

在这里寻找一个好的答案:

我应该使用varchar(n)或varchar(MAX)?

简单的答案是,从存储的angular度来看,它是相同的,但从查询优化的angular度来看,最好使用varchar(N)。

以下是Microsoft推荐的内容:

  • 当列数据条目的大小一致时使用char。
  • 当列数据条目的大小相差很大时,使用varchar。
  • 当列数据条目的大小相差很大时,使用varchar(max),大小可能会超过8,000字节。

REF

只是在这个问题上非常明确, 答案是否定的 。 它总是最好使用varchar(N),如果你知道大小不会改变,那么char(N)。 MAXtypes不支持也不能支持大部分原生SQL特性,因此您不能添加索引,执行连接,也不能对这些types进行有效的search。 顺便说一下,这是SQL Server中存在全文searchfunction的原因之一。

另外,varchar(max)会阻止对包含varchar(max)字段的整个表执行联机索引。 这会显着影响系统的性能。

如果已知字段的大小超过8K,则只应使用Varchar(max)。 在其他情况下,必须指定大小。 不这样做是糟糕的devise,并导致任何系统上最微不足道的性能问题。

一些参考:

  • TSQL:如何将本地时间转换为UTC? (SQL Server 2008)
  • 如何将单列值分割为多个列值?
  • tsql从函数或存储过程返回一个表
  • SQL中DateTime字段的时间部分
  • 你如何返回一个表的列名?
  • SQL Server中Oracle的RowID的等价物
  • nvarchar(MAX)将容纳的最大字符数是多less?
  • SQL,PL-SQL和T-SQL有什么区别?
  • 从SQL DATE获取仅月份和年份
  • 对于Nvarchar(Max),我只能在TSQL中获得4000个字符?
  • 为什么我不能在SQL Management Studio的开始/结束块中使用“创build模式”?