mysql - 为什么表 CHARSET 设置为 utf8mb4 而 COLLATION 设置为 utf8mb4_unicode_520_ci

标签 mysql wordpress phpmyadmin character-encoding collation

我最近注意到,当我开始一个新的 WordPress 项目时,我的表的排序规则会自动从 utf8_unicode_ci(我在从 phpMyAdmin 创建新数据库时选择)更改为 utf8mb4_unicode_520_ci.

另外,我在 phpMyAdmin 中的“常规设置”下注意到服务器连接排序规则默认为 utf8mb4_unicode_520_ci

我在 Ubuntu 17.04 上运行 MySQL Server 5.7.17 和 phpMyAdmin 4.6.6。

我的问题如下:

  1. 为什么会这样?
  2. 如果可能,我该如何防止这种情况发生?由于 utf8mb4,我在将 WP 站点迁移到不支持它的旧 MySQL 服务器时遇到了问题。
  3. 第 2 点是否可取?在 utf8 上使用字符集 utf8mb4 和在 utf8_unicode_ci 上使用排序规则 utf8mb4_unicode_520_ci 有什么好处吗?

最佳答案

过去只有utf8(又名utf8mb3); 将来,utf8mb4 将是默认字符集。现在 utf8mb4 是默认字符集。

过去,_general_ci 是默认排序规则;然后 _unicode_ci (Unicode 4.0) 更好,然后是 _unicode_520_ci (Unicode 5.20)。 future (MySQL 8.0),默认为_0900_ci_ai(Unicode 9.0)。

与此同时,道路上充满了 MySQL 过去的错误所产生的坑洼。而 WP 设计师正在驾驶一个没有注意到坑洼的大水箱。

MySQL 5.6 是一个大坑,它吞噬了许多 WP 用户,因为索引的 767 限制以及过长 VARCHAR(255) 上的 WP 索引以及使用 的可能性>utf8mb4。拥有 5.7.17 后,您已经过关了。 (您 future 向 8.0 的迁移将不会那么坎坷。)

也就是说,在 5.7.7+ 上新创建的数据库/表/列不应该遇到 767 问题,但是从旧版本(5.5.3+)迁移的东西可能会出现问题,特别是如果某些东西导致您更改为 utf8mb4 .

怎么办?我可能会用完空间试图拼出所有选项。因此,请提供数据的历史记录、升级路径(如果有)、当前设置、表的 ROW_FORMATCHARACTER SETCOLLATION 的列,SHOW VARIABLES LIKE 'char%';

的输出

你应该在哪里?对于 5.7.7+,只要可行,utf8mb4utf8mb4_unicode_520_ci。该字符集为您提供表情符号和所有中文(utf8 没有)。该排序规则是可用的最佳排序规则,尽管您可能很难注意到它的重要性。

注意:排序规则名称的第一部分是唯一可以使用的字符集。即 utf8_unicode_ci 不适用于 utf8mb4

对于 MySQL 8.0,有一个比标题中提到的更好的排序规则。通常,只需对所选字符集使用默认排序规则(除非您有特定语言需求的兼容性问题)。

关于mysql - 为什么表 CHARSET 设置为 utf8mb4 而 COLLATION 设置为 utf8mb4_unicode_520_ci,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/43644218/

相关文章:

php - Arduino 传感器读取不使用 phpmyadmin 和 xampp 上传到 mySql

mysql - 从 mysql 表中清除数据

PHP 显示 MySQL 搜索的搜索结果

php - 有没有办法从 wordpress 中的链接生成中排除域

php - 如何从语言菜单中删除标志

javascript - phpMyAdmin 发生致命 Javascript 错误

mysql - 使用phpmyadmin修改mysql表中的数据

mysql - 无法链接 Jenkins 管道中的两个 "sidecar"容器

mysql - 如何从 MySQL 中选择行而不包含跨两列的重复项

image - 为图像添加自动超链接