数据库设计中夸大字段大小

我的表中有一些字段是字符串，目前，大多数字段大小都有很高的字符限制。例如，街道名称为100个字符。使用大字段大小会受到惩罚吗？例如，如果我将此字段的限制更改为30个字符，那么尺寸会有所提高还是效率？大约有50个领域可能会缩小。

感谢您的建议。

如果你在谈论varchar和nvarchar则没有，也没有罚则，以允许更高的字段长度。

但是，需要注意一些注意事项：

• 可变长度字段（每个字段）每行有2个字节的开销。如果您的字段很短，则使用可能更有意义CHAR。 Varchar(2)例如，实际上每行使用2-4个字节，而CHAR(2)总是使用2。
• 很长的字段无法建立索引。 索引键集中所有字段的最大长度为900字节。
• 如果您允许的数据量超出预期，最终将获得意想不到的结果。 如果您允许使用100个字符作为街道名称，则有时您可能不知道该字段的其他数据（例如整个地址）。如果大小合适，则会在插入时出现错误。
• 允许非常宽的行可能导致页面拆分和碎片化。 如果行的长度超过8k，则需要将其拆分为多个数据页。其中许多因素实际上会损害性能。 通常，更窄更有效。

如果您的意思是“声明字段大小大于实际存储的任何值是否会受到惩罚？”，那么只要将其声明为varchar，答案是否定的。我所知道的每个SQL DB引擎仅存储数据中实际给定的字符数（加上长度值）。因此，如果将字段定义为varchar（100）但仅在其中存储10个字符，则它将仅在磁盘上占用10个字符（长度加上2个字节左右）。如有疑问，我通常会将varchar字段设置得非常大。

如果您的意思是“存储长字符字段是否会受到惩罚”，答案是肯定的。今天的磁盘空间很便宜，但它不是免费的，因此您不想无故浪费它。可能更重要的是，从磁盘读取数据需要时间，因此数据字段越长，程序变得越慢。如果对该字段进行了索引，这实际上会减慢您的检索速度，因为每次读取都必须将键值与此长字段进行比较。

请记住，如果给用户一个大数据输入字段，他们迟早会使用它。

话虽这么说，我会错在太大而不是太小的一边。磁盘空间足够便宜，您不希望强迫用户即时创建缩写，因为它们无法将实际数据放入可用字段中。我今天使用的系统的产品说明字段对于我们产品的许多真实名称来说太小了，因此用户必须缩写。当然，每个用户的缩写都不同，因此我们用二十种不同的方式来表达同一件事。

任何声称声明字段大小大于表中实际存储的字段大小的人都是不正确的。数据的实际大小（加上2字节的开销）是实际存储的内容，但它是列定义，用于根据执行计划确定估算值。因此，尽管声明一个varchar（1000）存储10个字符的值将只吃掉12个字符的磁盘空间，但是执行计划的估计效率将大大降低，并且结果将对结果产生负面影响，因为要授予该操作多少内存以及该操作是否只能在内存中执行，或者是否还需要tempdb驱动器空间。您可以将列设为varchar（1000），但引擎不知道您存储的所有值实际上都小于varchar（10），

字段长度检查是您“免费”获得的，这意味着您不必使用CHECK约束即可执行此操作。而且，例如，当您必须将数据上传到另一个数据库时，就不需要太大的数据值，该数据库已将同一数据元素限制为35个字符以符合国际标准地址。