sql-server – 使用MAX文本或更具体,更小的类型

有人正在审查我的DDL代码以创建表并建议,当他们看到我看到使用VARCHAR(256)字段用于文本时我希望它非常小,比如名字或其他什么,我应该总是使用VARCHAR(MAX)和链接 Why use anything but varchar(max).我读了它,但它似乎过时了,因为它专注于2005年,似乎没有提供任何真正的理由在所有文本字段上每行可能分配高达2 GB.

从性能,存储等角度来看,如何在现代版本的SQL Server中决定是使用VARCHAR(MAX)还是更小的更具体类型？ (例如,2008年,2012年,2014年)

解决方法

Should I always use (n)varchar(max) for text columns?

没有.

对于SQL Server,只有在没有替代方法时才应指定最大数据类型.应该选择正确的基类型(varchar或nvarchar),并指定适合于要存储的数据的显式最大长度.

无论列的类型是varchar(n)还是varchar(max),物理存储都是相同的,因此这不是问题.

不选择(n)varchar(max)的原因在于功能,计划质量和性能.

详尽的列表可能不实用,但除其他外,最大列：

特征

>需要单独的约束来强制执行最大长度
>不能是索引中的键(因此也没有唯一约束)
>可以阻止在线DDL(包括索引重建和添加新的非空列)
>通常不支持’较新’功能,例如列存储
>有关更多特定功能和限制,请参阅产品文档.一般模式是围绕最大数据类型存在尴尬的限制和限制.并非所有限制和副作用都记录在案.

性能

>在执行引擎中需要特殊处理,以考虑可能非常大的大小.通常,这涉及使用效率较低的代码路径和流式接口
>对于外部代码(以及其他SQL Server组件,如SSIS)可能会产生类似的意外后果,这些组件也必须准备好处理大小达2GB的数据
>假设内存授权计算中的宽度为4000字节.这可能会导致过多的内存预留,这会限制并发性,并将有价值的索引和数据页从高速缓存中推出
>禁用几项重要的性能优化
>可以延长锁定时间
>可能会阻止优化程序选择(非动态)搜索计划
>防止过滤器被推入扫描并寻找剩余物
>可能会增加tempdb压力和争用(取决于版本),因为变量和参数也可能被输入为max以匹配列定义

总之,不必要地使用max说明符有很多微妙(和不良)的副作用,这样做是没有意义的.使用单一声明的轻微“便利”不是一种补偿.

在上下文中评估每个类型,使用正确的基类型(varchar或nvarchar)和合理的显式长度.

进一步阅读：

> Performance comparison of varchar(max) vs. varchar(n)由Remus Rusanu
> Read Committed and Large Objects by Craig Freedman
> Capacity planning for tempdb
> Deletes that split pages and forwarded ghosts(我)

（编辑：广州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!