使用 ASCII/拉丁字符集是否可以加快数据库速度？

Question

对大多数字段使用 ASCII 字符集，然后仅对需要它的字段指定 UTF-8 似乎可以将数据库必须执行的 I/O 量减少 100%。

有人知道这是真的吗？

更新：以上并不是我真正的问题。我应该说：使用拉丁语作为默认字符集，然后只为需要它的字段指定

utf8mb4

。我们的想法是：使用 1 字节与 2 字节相比，I/O 应该提高 100%。抱歉造成混乱。

Answer 1

简短回答：不值得担心。

长答案：

两个问题：

• 速度：

将两种编码与相应的 _bin（ascii_bin 或 utf8_bin）进行比较

COLLATION

就像比较字节一样简单 - 所以没有显着差异。 其他排序规则可能有所不同，其中 ASCII 速度更快。 但是与获取行等的工作量相比，差异微不足道。

• 空间：

Ascii 是 utf8 的子集。 utf8 为每个 ascii 字符仅存储 1 个字节，就像 ascii 一样。 所以，没有空间差异。 （西欧的重音字母需要 1 字节 latin1 或 2 字节 utf8；因此不兼容且大小不同。）空间导致缓存，从而导致性能略有差异。

对于英文文本，节省 0%。 对于欧洲人来说，latin1 只能节省百分之几；对于世界上大多数其他地方来说，utf8 是唯一可行的解决方案。 对于中文和Emoji来说，utf8mb4是必须的。

• 临时表

在某些情况下，字符串占用的空间会扩展到潜在的最大值。

country_code CHAR(2) CHARACTER SET ...

对于 ascii 将占用 2 个字节； utf8 为 6 个字节。

底线：

使用 ascii 表示国家/地区代码、十六进制、邮政编码、uuid、md5 等。如果您要走向国际，和/或需要表情符号，请使您的“字符串”为 utf8mb4。 但这样做是因为它是“正确的”，而不是因为你会神奇地获得更快的速度；而是因为它是正确的。你不会的。 并在创建表时执行此操作；以后改就是坑。

Answer 2

@RickJames 是对的，您不必担心选择 ASCII 或 utf8 而不是 utf8mb4 来节省空间。

utf8 和 utf8mb4 是可变长度字符编码。 wikipedia 中的此表说明了字符如何自动占用 1、2、3 或 4 个字节，具体取决于编码的值。如果设置了一个字节的高位，则该字符使用一个附加字节，最多 4 个字节。

维基百科文章解释得很清楚：

前 128 个字符 (US-ASCII) 需要一个字节。接下来的 1,920 个字符需要两个字节进行编码，这涵盖了几乎所有拉丁字母的其余部分，以及希腊语、西里尔语、科普特语、亚美尼亚语、希伯来语、阿拉伯语、叙利亚语、Thaana 和 N'Ko 字母表，以及组合变音符号分数。基本多语言平面的其余部分中的字符需要三个字节，该平面包含几乎所有常用字符，包括大多数中文、日文和韩文字符。 Unicode 其他平面中的字符需要四个字节，其中包括不太常见的 CJK 字符、各种历史文字、数学符号和表情符号（象形符号）。

您无需执行任何操作即可选择单字节模式还是多字节模式。这就是编码的工作方式。每个字符自动使用它需要的字节数，不再多了。

因此，使用 utf8 相对于 utf8mb4 没有优势，使用 ASCII 相对于两者都没有优势，除非您需要限制字符串中允许的字符。

就其价值而言，MySQL 称为“utf8”的字符集是 utf8mb3 的别名，它是 UTF8 编码的前三个字节的实现。 MySQL 服务器团队博客 (https://mysqlserverteam.com/mysql-8-0-when-to-use-utf8mb3-over-utf8mb4/) 表示 utf8mb4 更快，至少考虑到 MySQL 8.0 中的性能改进，和 utf8mb3 应被视为已弃用。 MySQL 8.0.11 发行说明 说 utf8 将在 MySQL 的未来版本中被重新定义为 utf8mb4 的别名。