每次设置新的SQL表或varchar向现有表添加新列时,我都想知道一件事:的最佳价值是什么length。
假设您有一个名为nametype 的列varchar。因此,您必须选择长度。我想不出一个名称> 20个字符,但您永远不会知道。但是我总是使用四舍五入到下一个2 ^ n数字,而不是使用20。在这种情况下,我将选择32作为长度。我这样做是因为从计算机科学家的角度来看,数字2 ^ n even在我看来比其他数字要多,我只是假设下面的体系结构可以更好地处理这些数字。
另一方面,例如,当您选择创建varchar列时,MSSQL服务器会将默认长度值设置为50。那让我开始思考。为什么是50?它只是一个随机数,还是基于平均列长,还是什么?
不同的SQL Server实现(例如MySQL,MSSQL,Postgres等)也可能具有(也可能是)不同的最佳列长值。
据我所知,没有DBMS有任何“优化”可以使长度VARCHAR为a的2^n性能比max长度不是2的幂的性能更好。
我认为早期的SQL Server版本实际上将VARCHAR255的长度与最大长度较高的长度区别对待。我不知道是否仍然如此。
对于几乎所有的DBMS,所需的实际存储空间仅取决于您放入其中的字符数,而不取决于max您定义的长度。因此,从存储的角度(也可能是性能的角度),无论您将列声明为VARCHAR(100)还是都没有任何区别VARCHAR(500)。
您应该max将为VARCHAR列提供的长度看作是一种约束(或业务规则),而不是技术/实际的事物。
对于PostgreSQL来说,最好的设置是使用text不受长度限制CHECK CONSTRAINT的字符集,它将字符数限制为您的业务需求。
如果该要求发生变化,那么更改检查约束比更改表要快得多(因为不需要重写表)
可以对Oracle和其他对象应用相同的方法-在Oracle中,它VARCHAR(4000)不是,text而是。
我不知道SQL Server VARCHAR(max)和VARCHAR(500)SQL Server 之间是否存在物理存储差异。但是varchar(max)与相比,使用显然会对性能产生影响varchar(8000)。
看到此链接(由Erwin Brandstetter发表评论)
编辑2013-09-22
关于bigown的评论:
在9.2之前的Postgres版本中(我写初始答案时不可用),对列定义的更改确实重写了整个表,请参见例如此处。从9.2开始,情况不再如此,快速测试确认增加具有120万行的表的列大小实际上仅需0.5秒。
对于Oracle来说,从更改大表的varchar列所需的时间来看,这似乎也是正确的。但是我找不到任何参考。
对于MySQL,该手册会说 “ 在大多数情况下,ALTER TABLE为原始表创建一个临时副本 ”。我自己的测试证实了:ALTER TABLE在具有120万行的表上运行(与我对Postgres的测试相同)以增加列的大小需要1.5分钟。但是,在MySQL中,您不能使用“替代方法”来使用检查约束来限制列中的字符数。
对于SQL Server,我找不到明确的声明,但是执行增加varchar列大小的执行时间(同样是上表的120万行表)表明没有重写。
编辑2017-01-24
似乎我(至少部分地)对SQL Server错误。请参阅Aaron Bertrand的答案,该答案表明a nvarchar或varcharcolumn 的声明长度对性能有很大的影响。来源:stack overflow
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。