想知道这两种数据类型将占用多少实际存储空间，因为 MySQL 文档对此事有些不清楚。
CHAR(M) M × w 字节，0
VARCHAR(M), VARBINARY(M) L + 1 个字节，如果列值需要 0 – 255 字节，如果值可能需要超过 255 个字节，则为 L + 2 个字节
在我看来，这似乎意味着，给定一个 utf8 编码的数据库，一个 CHAR 将始终占用每个字符 32 位，而 VARCHAR 将占用 8 到 32 位，具体取决于所存储字符的实际字节长度。那是对的吗？或者 VARCHAR 是否意味着 8 位字符宽度，并且存储多字节 UTF8 字符实际上会消耗 VARCHAR 中的多个“字符”？或者 VARCHAR 是否也总是每个字符存储 32 位？很多可能性。
我以前不必担心这么多，但我开始达到内存临时表大小限制，我不一定要增加 MySQL 的可用池（第二次)。
【问题讨论】：
标签： mysql character-encoding sqldatatypes
CHAR 和 VARCHAR 都计算字符数。考虑到字符编码和长度，它们都计算了它们可能需要的最大存储空间。对于 ASCII，每个字符 1 个字节。对于 UTF-8，每个字符 3 个字节（不是您期望的 4 个字节，因为 MySQL's Unicode support is limited 出于某种原因，并且它不支持在 UTF-8 中需要 4 个字节的任何 Unicode 字符）。到目前为止，CHAR 和 VARCHAR 是相同的。
现在，CHAR 继续保留此数量的存储空间。
VARCHAR 而是分配了 1 或 2 个字节，这取决于这个最大存储是
有趣的是，这使得 85 成为 UTF-8 的神奇数字VARCHAR：
VARCHAR(85) 使用 1 个字节作为长度，因为 85 个 UTF-8 字符的最大可能长度为 3 × 85 = 255。VARCHAR(86) 使用 2 字节作为长度，因为 86 个 UTF-8 字符的最大可能长度为 3 × 86 = 258。【讨论】：
utf8 存储不仅残缺不全，也不是标准的 UTF-8。 utf8 编码字符串的存储大约是常规 UTF-8 编码字符串的两倍，因此效率更低。
COMPACT 和 REDUNDANT）因此一行占用的空间取决于正在使用的空间。它不再像以前那样简单，当时唯一常用的存储引擎是 MyISAM。无论如何，1字节的差异无论如何都可以忽略不计。您更有可能关心 InnoDB 中键的最大长度，即 768 字节。因此 UTF-8 VARCHAR(256) 不能成为键的一部分。一个 UTF-8 VARCHAR(255) 字段可以是一个键。