varchar 列的长度 - 使用 255 有优势吗？

Question

我经常遇到列是varchar(255)，所以大概这是各种约定。255 是 2^8 - 1。那么 2^n - 1 的长度有什么“神奇”之处吗？或者只是专门255？某些特定varchar长度是否有性能或存储优化优势？或者这只是不再适用于当前版本的 MariaDB 和 MySQL 的旧智慧？

Answer 1

我偶尔会反对 255。当然，“255”曾经有一些原因，但许多不再有效，甚至适得其反。

在 MySQL 中，有理由停止在 191、255、767、3071、64K 和其他值。有些依赖于 Engine，有些依赖于CHARACTER SET，等等。

AVARCHAR存储为 1 或 2 字节的长度加上足够的字节存储在您指定的任何字符集中的当前文本中。然而，1或2个选择是不仅由单个列驱动; 它由总行大小驱动。也就是说，这不是使用 255 的有效借口。

使用长度为

• 足够大到保守地永远不会被超越，但
• 小到看似合理。

虽然我在咆哮...... CHAR（固定长度）很少被建议。几乎总是应该是CHARACTER SET ascii——country_code、postal_code、Y/N、M/F、MD5、UUID、base64 等（MD5 和 UUID 应该更进一步，但这是另一个咆哮。）

盲目使用“255”的潜在负面影响：

• 如果您有很多列，您可能会达到最大行大小限制并且CREATE TABLE会失败。
• 您可能会溢出索引大小的限制。
• 复杂SELECTs可能需要一个临时表，并可能使用MEMORY它。在这种情况下，VARCHAR(255)变为CHAR(255)临时表。而且，如果使用 utf8，则每行 755 个字节！（8.0 修复了这个设计缺陷？）

相关：不要盲目使用BIGINT所有数字。它需要 8 个字节。EvenINT是矫枉过正，4 个字节。见MEDIUMINT、SMALLINT、 和TINYINT。请注意，(2)onINT(2)没有任何意义；它仍然需要4个字节。

Answer 2

在某个时间点，这是 Sybase 和派生 SQL Server 中列的最大长度。我相信其他人复制它是为了保持兼容性，因此将应用程序/SQL 迁移到新平台并不困难，因为当时每个人都在争夺市场份额。

除了兼容性之外，没有真正的理由让它永久存在。我注意到这些天它似乎已被 varchar(max) 取代。