设置varchar(8000)有什么后果?


22

由于varchar占用的磁盘空间与字段大小成正比,因此是否有任何原因为什么我们不总是将varchar定义为最大值,例如varchar(8000)在SQL Server上?

在创建表上,如果我看到有人在做什么,varchar(100)我应该告诉他们不,你错了,你应该怎么做varchar(8000)


我认为我们必须在创建表和存储过程的参数声明之间进行区分。对于第二种解释,请参阅我的问题dba.stackexchange.com/questions/1772/…– bernd_k 2011
6

Answers:


18
  • 长度是对数据的约束(如CHECK,FK,NULL等)
  • 行超过8060字节时的性能
  • 不能具有唯一性约束或索引(键列宽度必须小于900)
  • 默认值为SET ANSI PADDING ON =可能存储大量尾随空格
  • SQL Server将假定平均长度为4000,以进行排序操作,并以此为基础分配内存(需要找到支持此操作的链接,但在我这样做时会生锈:-)

摘要:不要这样做。


当行超过8060字节时的性能。那是指实际使用的字节,而不是最大允许的字节?
bernd_k 2011年

@bernd_k:8060 =一行的最大数据量将适合单个8192页。包括行开销。剩余(132字节)=页面开销
gbn

这意味着,当真正使用更大的尺寸时,性能会下降,而并非纯粹由于事实而定,允许使用它。
bernd_k 2011年

@bernd_k:任何性能下降都是由1.排序等的内存分配2.行溢出(> 8060字节)引起的。在满足这些条件之前,每个varchar(8000)中都包含10个字符的事实是无关紧要的(SQL稍后会警告索引键可能存在错误)
gbn

用varchar(100)列填充100字节长度的字段对表进行排序是否值得另一个问题,因为排序假定平均50个字符?
bernd_k 2011年

7

假设您指的是SQL Server,我可以想到一个。

表格中行的大小(8K)有一个限制,SQL使您可以定义理论上可能超出该限制的varchar字段。因此,如果用户在与此相关的字段中放入过多数据,则可能会出错。

从SQL 2K8开始,您可以超过此限制,但是会影响性能

此外,还进行了整个合理性检查,将大小限制为您希望数据看起来的样子。如果您想要无限制的长度字段,为什么不使用text或ntext?


所以text和ntext数据类型的存储方式不会影响性能?
乍得

这些类型对表的8K行大小限制的贡献不大,因为实际数据存储在表皮下的单独表中,而不是与其余列内联。仍然会对性能产生影响,但是有不同的原因。也有对这些领域的功能支持限制比较为varchar和nvarchar的时候
JohnFx

不推荐使用text和ntext,而推荐使用varchar(max)。
Phil Helmer

3

当然,这取决于在现场存储哪些信息?

由于多种原因,某些东西将具有最大长度,如果必须具有最大长度,则该长度应为字段的长度。

如果理论上没有最大长度,那么我会问为什么要使用varchar。


3

在Oracle数据库的上下文中,我了解到始终对数据库列使用最小的字段大小有一个陷阱。

通过导入导出将数据从具有单字节排序规则的数据库移动到具有多字节排序规则的数据库(如Oracle XE)时,字节长度可能会增加,并且无法将数据导入到由导入创建的表中。当然,Oracle可以选择将varchar2长度定义为char或字节。

我的意思是,定义字段总是尽可能小并不总是明智的。我已经看到了很多更改表,以在以后增加字段(由于更改的需求所致)。

此处有20%-100%的未使用字段可供讨论。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.