仅使用MySQL字符时，utf8mb4_0900_ai_ci 8与utf8mb4_0900_ai_ci大小不同吗？

Question

如果我只使用ASCII字符，那么VARCHAR (255)和utf8mb4_0900_ai_ci在磁盘上的大小会比使用ASCII的VARCHAR (255)大吗？

Answer 1

Fiddle错了。

あ A い I う U え E お O.

声明客户端是用utf8 (或utf8mb4)编码的20个字符/40个字节。但是如果你声称它是在latin1中，它会导致Mojibake或“双重编码”，因此Fiddle显示了30和48。

あ A い I う U え E お O.  --> E38182 41 E38184 49 E38186 55 E38188 45 E3818A 4F 2E

有关错误所在的进一步讨论，请参阅https://stackoverflow.com/questions/38363566/trouble-with-utf8-characters-what-i-see-is-not-what-i-stored中的“双重编码”。我没有“修复”Fiddle的源代码。

也就是说，E38182是HIRAGANA字母A：あ的三个十六进制字节

但是，如果您将E38182 (etc)视为latin1，则它显示为゠A ㄠI ㆠU ㈠E ㊠O.。然后，如果您再次转换为utf8，您将得到

C3A3 C281 E2809A 20 41 20 C3A3 C281 E2809E 20 49 20 ...

您仍然可以识别空格(20)、A (41)、I (49)等，但是Hiragana字符已经损坏。

您不会看到Fiddle中的双重编码，因为浏览器“足够好”来“修复”您的错误。(这使得弄清楚到底出了什么问题是非常邪恶的。)

中国的六边形是E683B3 E79C8B E4BB80 E9A0AD E6B885 E58FAA E582B7 E7B2BE EFBC8C E4B8AD E7BE8E E8A780 E79A84 E68EA5 E5A794 E4B8BB E5A794 E58091 E5A794 E5A794 E58091 E5A794 E4B8BB E5A794 E58091 E5A794 E4B8BB E58091 E5A794 E4B8BB E58091 E5A794 E58091 E5A794 E58091 E683B3 19 en21 en23 09。

(末尾的制表符(09)可能是格式化的人为手段。)

双编码以C3A6 C692 C2B3 (来自EF、BC、8C) C3A7 C593 E280B9 C3A4 C2BB E282AC C3A9 C2A0 C2AD C3A6 C2B8 E280A6开始。

回到标题问题--即使你只使用ascii，也有细微的差别。

您可能不会遇到任何可测量的差异。这里有一些可能性。

• 某些临时表操作可能会更快达到极限。(这个问题在5.7中存在，但在构建临时表时，通过将VARCHAR转换为CHAR，在8.0中可能已经消除了更多问题。)
• 我还没有看到一个基准测试，它显示出utf8mb4排序规则对于ascii文本的速度是否快于CHARACTER SET、latin1或ascii。
• 字符集utf8mb4的索引限制比字符集ascii短。他们可能是VARCHAR(3072)对VARCHAR(768)。

Answer 2

除非MySQL做了一些奇怪的事情，否则只使用ASCII字符(即只有0-127值)应该是完全相同的编码，因此在ASCII、UTF-8和许多其他8位代码页之间应该是完全相同的大小。只有当您到达高于127 (或0x7F)的代码点时，UTF-8才会开始需要额外的空间(尽管从技术上讲，标准ASCII只包含值0- 127，因此没有超过127的代码点，因此所有ASCII代码点在UTF-8中都是相同的编码，这毕竟是UTF-8的设计目标:完全的ASCII兼容性)。