sql - 为什么使用较短的 VARCHAR(n) 字段？

Question

经常建议选择尽可能窄的数据库字段大小。我想知道这在多大程度上适用于 SQL Server 2005 VARCHAR 列:在 VARCHAR(255) 字段中存储 10 个字母的英语单词不会比在 VARCHAR(255) 字段中占用更多的存储空间一个 VARCHAR(10) 字段。

还有其他原因限制 VARCHAR 字段的大小以尽可能接近数据的大小吗？我在想

• 性能:在选择、过滤和排序数据时使用较小的 n 是否有优势？
• 内存，包括应用程序端 (C++)？
• 样式/验证:您认为限制列大小以强制无意义的数据导入失败(例如 200 个字符的姓氏)有多重要？
• 还有什么吗？

背景:我帮助数据集成商设计数据流到数据库支持的系统中。他们必须使用限制数据类型选择的 API。对于字符数据，仅n <= 255的VARCHAR(n)可用； CHAR、NCHAR、NVARCHAR 和 TEXT 不是。我们正在尝试制定一些“良好实践”规则，但问题是，即使对于实际最大大小永远不会超过 30 的数据，使用 VARCHAR(255) 是否确实有害字节左右。

一张表的典型数据量是 1-10 Mio 记录，最多 150 个属性。查询性能(SELECT，经常包含大量 WHERE 子句)和应用程序端检索性能至关重要。

Answer 1

1. 数据完整性 - 迄今为止最重要的原因。如果您创建一个名为 Surname 且包含 255 个字符的列，那么您可能会得到的不仅仅是姓氏。您将获得名字、姓氏、中间名。你会得到他们最喜欢的宠物。你会得到“会计部的三角头发的爱丽丝”。简而言之，您将使用户可以轻松地将该列用作注释/姓氏列。您希望上限能够阻止用户尝试在该列中输入姓氏以外的内容。如果您有一列需要特定长度(例如，美国税务标识符为 9 个字符)，但该列是 varchar(255)，其他开发人员会想知道发生了什么和 你也可能得到垃圾数据。

2. 索引和行限制。在 SQL Server 中，IIRC 的限制为 8060 字节。包含大量数据的大量非 varchar(max) 列很快就会超出该限制。此外，索引的 IIRC 宽度上限为 900 字节。因此，如果您想对姓氏列和其他一些包含大量数据的列建立索引，则可能会超出此限制。

3. 报告和外部系统。作为报表设计者，您必须假设如果声明最大长度为 255 的列，则它可以有 255 个字符。如果用户能做到，他们就会这么做。因此，可以说“它可能不会超过 30 个字符”。与“它不能超过 30 个字符”完全不同。永远不要依赖前者。作为报表设计者，您必须解决用户将一堆数据输入到列中的可能性。这要么意味着截断值(如果是这种情况，为什么还要有额外的可用空间？)，要么使用 CanGrow 制作出一团糟的报告。不管怎样，如果列的大小与实际存储的数据不相符，其他开发人员就很难理解列的意图。