问对所有基于文本的字段使用泛型varchar(255)是否有缺点？

EN

我和你在一起。对细节的过分关注是一种令人头疼的事情，而且价值有限。

曾几何时，磁盘是一种宝贵的商品，我们用汗水子弹来优化它。存储的价格下降了1000倍，这使得花在压缩每个字节上的时间变得不那么有价值了。

如果只使用CHAR字段，则可以获得固定长度的行。如果您为字段选择了准确的大小，这可以节省一些磁盘的实际大小。您可能会得到更密集的数据(用于表扫描的I/O更少)和更快的更新(更容易定位块中的空闲空间以进行更新和插入)。

但是，如果您高估了自己的大小，或者实际的数据大小是可变的，那么最终会浪费CHAR字段的空间。数据最终将变得不那么密集(导致更多的I/O用于大型检索)。

通常，尝试将大小放在可变字段上所带来的性能好处很小。您可以通过使用VARCHAR(255)与CHAR(x)进行比较来轻松地进行基准测试，以查看是否可以测量差异。

但是，有时候，我需要提供一个“小”、“中”、“大”的提示。因此，我使用16、64和255作为大小。

如今，我无法想象这真的有多重要了。

使用可变长度字段会带来计算开销，但在CPU过多的今天，它甚至不值得考虑。I/O系统是如此缓慢，以至于不存在有效处理可变字符的任何计算成本。事实上，varchar的价格在计算上可能是通过使用可变长度字段而不是固定长度字段来节省磁盘空间量。您很可能有更大的行密度。

现在，varchar字段的复杂性在于您不能通过记录编号轻松定位记录。当您有一个固定长度的行大小(具有固定长度字段)时，计算行id所指向的磁盘块是很容易的。使用可变长度的行大小，这类数据就会从窗口中消失。

因此，现在您需要维护某种类型的记录号索引，就像任何其他主键一样，或者需要创建一个健壮的行标识符来编码细节(如块等)。添加到标识符中。但是，如果您这样做了，那么如果该行被移动到持久存储上，就必须重新计算id。没什么大不了的，只需要重写所有的索引条目，并确保你a)永远不会将它暴露给消费者，或者b)永远不会断言这个数字是可靠的。

但是因为我们现在有varchar字段，所以varchar( 16 )优于varchar(255)的唯一值是DB将对varchar(16)强制执行16个字符的限制。如果假设DB模型实际上代表物理数据模型，那么拥有字段长度可能是有价值的。然而，如果它只是“存储”而不是“模型和存储”，那么就没有任何必要了。

然后，您只需区分可索引的文本字段(如varchar)和不可索引的文本字段(如文本或CLOB字段)。可索引字段往往有大小限制以便于索引，而CLOB字段则没有(在合理范围内)。

在我的经验中，如果你允许255个字符的数据类型，一些愚蠢的用户(或一些有经验的测试人员)实际上会填满它。

然后您就会遇到各种各样的问题，包括在报告和应用程序的屏幕显示中为这些字段留出多少空间。更不用说在数据库中超过每行数据限制的可能性(如果这255个字符域中有多个)。

在开始时选择一个合理的限制要容易得多，然后通过应用程序和数据库强制执行。