我偶尔会抱怨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会失败。
• 您可能会超出索引大小的限制。
• ComplexSELECTs可能需要一个临时表，并且可以使用MEMORY它。在这种情况下，VARCHAR(255)成为CHAR(255)临时表。而且，如果使用 utf8，则每行 755 个字节！（8.0 修复了这个设计缺陷？）

相关：不要盲目使用BIGINT所有数字。它需要 8 个字节。EvenINT是多余的，只有 4 个字节。请参阅MEDIUMINT、SMALLINT和TINYINT。请注意，(2)onINT(2)没有任何意义；它仍然需要 4 个字节。