基于字符的数据的数据库列大小
我刚刚遇到一个数据库，其中所有基于字符的列的大小均以8的倍数指定（例如，Username = varchar（32），Forename = nvarchar（128）等）这会影响数据库的性能吗？还是完全没有意义？基于字符的数据的数据库列大小
谢谢。
N.B.这是在SQL 2000数据库中。
由于它们是VARchars，所使用的实际空间基于内容。如果他们是CHAR，我会开始担心。
-Edoode
看起来像我过早的优化。
我不认为这会使数据库发生任何性能变化。
这可能只是一些老学校开发者的习惯。正如所说 - varchar只要它需要，所以32或33并不重要，当字符串长度是例如22.
“这是否会影响数据库的性能或完全是无意义？”
它对性能几乎没有影响（不是没有，但很少）。它可能会对备用空间分配产生影响，因为使用此方案“最大”行大小可能相当大。每页几行可以减慢大表检索的速度。
但是，与不恰当的索引相比，差异通常是微观的。
获得大小“正确”是不值得的时间。在过去的日子里，老派的DBA每个角色都流汗了。磁盘过去非常昂贵，每个字节都会对成本产生实质性的影响。
现在这个磁盘非常便宜，DBA的时间浪费在大小比磁盘更大的成本上。
如果它们都是5或10的倍数，那么你会有同样的担忧吗？这是正常情况下发生的情况。
我从来没有见过它在表格存储，连接或基本操作上有所不同。
但我已经看到它在涉及字符串处理方面有所作为。
在SQL Server 2005中，我已经看到varchar大小有显着差异的唯一情况是，当事情被转换为varchar（MAX）或UDF时。这里似乎有一些差异 - 例如，我有一个系统/进程正在移植一些关键列，这些列必须连接在一起形成另一个伪关键字段（直到我能够重构这种可憎的关系）和在中间CTE或嵌套查询中尽可能快地将结果强制转换为varchar（45）。我见过UDF取得和返回一个varchar（MAX）比一个取得和返回varchar（50）表现得差得多的情况，比方说。例如，某人（也许是我！）正在试图做出未来证明的修剪或填充功能。 varchar（MAX）有它的位置，但根据我的经验，它可能会对性能造成危险。
我不认为我分析了varchar（50）和varchar（1000）之间的区别。