使用ascii/拉丁字符集是否加快了数据库的速度?

ssgvzors  于 2021-06-20  发布在  Mysql
关注(0)|答案(2)|浏览(475)

似乎对大多数字段使用ascii字符集,然后只为需要它的字段指定utf8,这将使数据库必须执行的i/o量减少100%。
有人知道这是不是真的吗?
更新:以上不是我的问题。我应该说:使用拉丁语作为默认字符集,然后只为需要它的字段指定utf8mb4。其思想是:使用1字节对2字节应该将i/o提高100%。抱歉给你添麻烦了。

fiei3ece

fiei3ece1#

简而言之:不值得担心。
长话短说:
两个问题:
速度:
比较两种编码与相应的_bin(ascii_bin或utf8_bin) COLLATION 就像比较字节一样简单——所以没有明显的区别。其他排序规则可能不同,ascii更快。但与获取行等的努力相比,这种差异是微不足道的。
空间:
ascii是utf8的子集。utf8只为每个ascii字符存储1个字节,就像ascii一样。所以,没有空间差异(西欧的重音字母需要1字节拉丁文1或2字节utf8;因此不兼容并且大小不同。)空间会导致缓存,这会导致性能上的细微差别。
对于英文文本,节省0%。对欧洲人来说,拉丁人只会省几个百分点;对于世界上大多数国家来说,utf8是唯一可行的解决方案。对于中文和表情符号,utf8mb4是必须的。
临时表格
在某些情况下,字符串占用的空间会扩展到潜在的最大值。 country_code CHAR(2) CHARACTER SET ... ascii码需要2个字节;utf8为6字节。
底线:
使用ascii表示国家代码、十六进制、邮政编码、uuid、md5s等。如果您要出国,和/或需要emoji,请将您的“字符串”设置为utf8mb4。但做这件事是因为它是“正确的”,而不是因为你会神奇地获得更快的速度;你不会的。当你创建一个表的时候就去做;以后再换是坑里的事了。

zbdgwd5y

zbdgwd5y2#

@rickjames是对的,您不应该担心通过选择ascii或utf8而不是utf8mb4来节省空间。
utf8和utf8mb4是可变长度字符编码。wikipedia的这个表说明了字符是如何根据编码的值自动获取1、2、3或4个字节的。如果设置了字节的高位,则字符将使用额外的字节,最多4个字节。

维基百科的文章解释得很清楚:
前128个字符(us ascii)需要一个字节。接下来的1920个字符需要两个字节来编码,这涵盖了几乎所有拉丁字母表的其余部分,还有希腊语、西里尔语、科普特语、亚美尼亚语、希伯来语、阿拉伯语、叙利亚语、塔纳语和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应该被认为是不赞成的。MySQL8.0.11发行说明说,在MySQL8的未来版本中,utf8将被重新定义为utf8mb4的别名。

相关问题