想知道这两种数据类型将占用多少实际存储空间，因为 MySQL 文档对此事有些不清楚。
CHAR(M) M × w 字节，0 <= M <= 255，其中 w 是字符集中最大长度字符所需的字节数
VARCHAR(M), VARBINARY(M) 如果列值需要 0 – 255 个字节，则为 L + 1 个字节，如果值可能需要超过 255 个字节，则为 L + 2 个字节
这对我来说似乎意味着，给定一个 utf8 编码的数据库，一个 CHAR 将始终占用每个字符 32 位，而 VARCHAR 将占用 8 到 32 位，具体取决于所存储字符的实际字节长度。那是对的吗？或者 VARCHAR 是否意味着 8 位字符宽度，并且存储多字节 UTF8 字符实际上会消耗 VARCHAR 中的多个“字符”？或者 VARCHAR 是否也总是每个字符存储 32 位？这么多的可能性。
我以前不必担心这么多，但我开始达到内存临时表大小限制，我不一定要增加 MySQL 的可用池（第二次）。
CHAR并且VARCHAR都计算字符。考虑到字符编码和长度，它们都计算了它们可能需要的最大存储空间。对于 ASCII，每个字符 1 个字节。对于 UTF-8，每个字符 3 个字节（不是您期望的 4 个字节，因为MySQL 的 Unicode 支持由于某种原因受到限制，并且它不支持在 UTF-8 中需要 4 个字节的任何 Unicode 字符）。到目前为止，CHAR和VARCHAR都是一样的。
现在，CHAR继续并保留此数量的存储空间。
VARCHAR而是分配 1 或 2 个字节，具体取决于此最大存储空间是 < 256 还是 ≥ 256。条目实际占用的空间量是这 1 或 2 个字节，加上字符串实际占用的空间量。
有趣的是，这使得 85 成为 UTF-8 的神奇数字VARCHAR：
VARCHAR(85)使用 1 个字节作为长度，因为 85 个 UTF-8 字符的最大可能长度为 3 × 85 = 255。VARCHAR(86)使用 2 字节作为长度，因为 86 个 UTF-8 字符的最大可能长度为 3 × 86 = 258。