utf8mb4和utf8有啥区别

Posted 2023-04-28

没用过，也没试过那么高的mysql版本。不过你发的手册链接说了以往mysql里的utf8一个字符最多3字节，只支持BMP这部分的unicode编码区，BMP是从哪到哪，到http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters这里看，基本就是0000～FFFF这一区。而utf8mb4则扩展到一个字符最多能有4字节，所以能支持更多的字符集。utf8mb4isasupersetofutf8utf8mb4兼容utf8，且比utf8能表示更多的字符。至于什么时候用，看你的做什么项目了，到http://witmax.cn/unicode-list.html看unicode编码区从1～126就属于传统utf8区，当然utf8mb4也兼容这个区，126行以下就是utf8mb4扩充区，什么时候你需要存储那些字符，你才用utf8mb4,否则只是浪费空间。 参考技术A 以往mysql里的utf8一个字符最多3字节，只支持BMP这部分的unicode编码区，
BMP是从哪到哪，基本就是0000～FFFF这一区。
而utf8mb4则扩展到一个字符最多能有4字节，所以能支持更多的字符集。
SQL code
utf8mb4 is a superset of utf8本回答被提问者采纳

utf8_general_ci 和 utf8_unicode_ci 有啥区别？ [复制]

【中文标题】utf8_general_ci 和 utf8_unicode_ci 有啥区别？ [复制]

【英文标题】：What are the differences between utf8_general_ci and utf8_unicode_ci? [duplicate]utf8_general_ci 和 utf8_unicode_ci 有什么区别？ [复制]

【发布时间】：2010-11-05 09:45:23

【问题描述】：

可能重复：What's the difference between utf8_general_ci and utf8_unicode_ci

我有两个 unicode 选项，看起来很有希望用于 mysql 数据库。

utf8_general_ci unicode (multilingual), case-insensitive
utf8_unicode_ci unicode (multilingual), case-insensitive

你能解释一下 utf8_general_ci 和 utf8_unicode_ci 有什么区别吗？在设计数据库时选择其中一个有什么影响？

【问题讨论】：

另见***.com/questions/766809/…

【参考方案1】：

utf8_general_ci 是一个非常简单的排序规则——在 Unicode 上，非常糟糕——排序规则，它在一般 Unicode 文本上给出不正确的结果。它的作用是：

转换为 Unicode 规范化形式 D 以进行规范分解 删除任何组合字符 转换为大写

这在 Unicode 上无法正常工作，因为它不理解 Unicode 大小写。单独的 Unicode 大小写比具有 ASCII 意识的方法可以处理的要复杂得多。例如：

“ẞ”的小写字母是“ß”，但“ß”的大写字母是“SS”。 有两个小写的希腊 sigma，但只有一个大写的；考虑“Σίσυφος”。 像“ø”这样的字母不会分解为“o”加变音符号，这意味着它不会正确排序。

还有许多其他的微妙之处。

utf8_unicode_ci 使用标准 Unicode Collation Algorithm，支持所谓的扩展和连字，例如： 德语字母 ß (U+00DF LETTER SHARP S) 在“ss”附近排序 字母 Œ (U+0152 LATIN CAPITAL LIGATURE OE) 在“OE”附近排序。

utf8_general_ci 不支持扩展/连字，它可以排序 所有这些字母都是单个字符，有时顺序错误。

utf8_unicode_ci通常对于所有脚本都更准确。 例如，在 Cyrillic 块上： utf8_unicode_ci 适用于所有这些语言： 俄语、保加利亚语、白俄罗斯语、马其顿语、塞尔维亚语和乌克兰语。 虽然 utf8_general_ci 仅适用于西里尔文的俄语和保加利亚语子集。 白俄罗斯语、马其顿语、塞尔维亚语和乌克兰语中使用的额外字母 排序不好。

utf8_unicode_ci 的代价是它是一个一点位 比utf8_general_ci 慢。但这就是你为正确性付出的代价。要么你可以有一个错误的快速答案，或者一个非常慢的答案是正确的。你的选择。 很难证明给出错误答案是合理的，因此最好假设utf8_general_ci 不存在并始终使用utf8_unicode_ci。好吧，除非你想得到错误的答案。

来源：http://forums.mysql.com/read.php?103,187048,188748#msg-188748

【讨论】：

语言列表的道具

看起来这个答案是直接从mysql论坛forums.mysql.com/read.php?103,187048,188748#msg-188748复制而来的

复制/粘贴答案时不会阻止您引用原始来源：P

那你为什么要使用utf8_general_ci 而不是utf8_unicode_ci？

永远不要使用utf8_general_ci http://***.com/a/766996/570763

【参考方案2】：

来自Unicode Character Sets 中的MySQL documentation：

对于任何 Unicode 字符集，使用 _general_ci 排序规则执行的操作比使用 _unicode_ci 排序规则执行的操作要快。例如，utf8_general_ci 排序规则的比较比utf8_unicode_ci 的比较更快，但正确性稍差。原因是utf8_unicode_ci支持扩展等映射；也就是说，当一个字符比较等于其他字符的组合时。例如，在德语和其他一些语言中，“ß”等于“ss”。 utf8_unicode_ci 还支持缩写和可忽略的字符。 utf8_general_ci 是不支持扩展、收缩或可忽略字符的传统排序规则。它只能在字符之间进行一对一的比较。