varchar（128）是否优于varchar（100）

Question

快速提问。如果我使用十进制字段限制或十六进制（例如16,32,64而不是10,20,50），从存储数据的角度来看是否重要？

我问，因为我想知道这是否与HDD上的群集有关？

谢谢！

Answer 1

如果需要存储长度超过100个字节的字符串，VARCHAR（128）优于VARCHAR（100）。

否则，它们之间几乎没有选择;您应该选择最适合您可能需要存储的数据的最大长度的那个。您将无法衡量它们之间的性能差异。除此之外，DBMS可能只存储您发送的数据，因此如果您的平均字符串是16字节，那么它只会使用16（或者更可能是17 - 允许1个字节来存储长度）字节在磁盘上。较大的大小可能会影响页面上可以容纳多少行的计算 - 这是有害的。因此，选择足够的最小尺寸是有道理的 - 不要浪费，不要浪费。

因此，总而言之，两者在性能或磁盘使用方面差别不大，并且与方便的二进制边界对齐并没有真正有所作为。

Answer 2

如果它是一个C-Program，我也会花些时间考虑一下。但是对于数据库，我会把它留给数据库引擎。

数据库程序员花了很多时间考虑最佳内存布局，所以只需告诉数据库你需要什么，它就会以最适合数据库引擎的方式存储数据（通常）。

如果要对齐数据，则需要完全了解内部数据组织：字符串是如何存储的？一个，两个或四个字节来存储长度？它是以普通字节序列存储还是以UTF-8 UTF-16 UTF-32编码？ DB是否需要额外的字节来标识NULL或＆gt; MAXINT值？也许字符串存储为NUL终止的字节序列 - 然后内部需要一个字节。

对于VARCHAR，它不是必需的，DB将始终为您的字符串分配100（128）个字节。也许它只存储指向实际数据空间的指针。

所以我强烈建议使用VARCHAR（100），如果这是你的要求。如果数据库决定以某种方式对齐它，那么也有额外内部数据的空间。

其他方面：假设你使用VARCHAR（128）并且所有东西都聚集在一起：数据库为你的数据分配128个字节。此外，它需要2个字节来存储实际的字符串长度 - 使130个字节 - 然后它可能是数据库将数据与下一个（比如说32个字节）边界对齐：磁盘上所需的实际数据现在是160个字节8 - }

Answer 3

是的，但事情并非那么简单。有时128可能比100好，有时，反过来。

那是怎么回事？ varchar只会根据需要分配空间，因此，如果您将hello world存储在varchar(100)中，则会占用varchar(128)中与null完全相同的空间。

问题是：如果你填满行，你会不会达到“阻止”限制/边界？

数据库将数据存储在块中。它们具有固定大小，例如512（可以为某些数据库配置此值）。所以问题是：数据库必须读取多少个块才能获取每一行？跨越几个块的行将需要更多的I / O，因此这会降低您的速度。

但同样：这不取决于列的理论最大大小，而是取决于a）你有多少列（每列需要一点空间，即使它是空的或number），b ）你有多少固定宽度的列（decimal / char，{{1}}），最后c）你在变量列中有多少数据。