为什么表CHARSET设置为utf8mb4,COLLATION设置为utf8mb4_unicode_520_ci

我最近注意到,当我开始一个新的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.

我的问题如下:

为什么会这样？

如果可能,我该如何防止这种情况？由于utf8mb4,我在将WP站点迁移到不支持它的旧MySQL服务器时遇到了问题.

第2点是可取的吗？使用charset utf8mb4优于utf8,以及整理utf8mb4_unicode_520_ci超过utf8_unicode_ci有什么好处？

Rick James.. 32

在过去,只有utf8; 在将来,utf8mb4将是默认字符集.

在过去,utf8mb4是默认的整理; 然后_general_ci(Unicode 4.0)更好,然后_unicode_ci(Unicode 5.20).将来(MySQL 8.0),默认为_unicode_520_ci(Unicode 9.0).

与此同时,道路充满了MySQL过去的错误所产生的坑洼.WP设计师驾驶着一辆没有注意到坑洼的大坦克.

MySQL 5.6是一个巨大的坑洼,吞噬了许多WP用户,因为索引上的767限制以及过长的WP索引_0900_ci_ai和使用的可能性VARCHAR(255).拥有5.7.17你已经远远超过了它.(你将来的8.0会变得不那么坎坷.)

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

该怎么办？我可能会用尽空间试图拼出所有选项.因此,提供数据的历史记录,升级路径(如果有),当前设置,utf8mb4表格,列ROW_FORMAT和CHARACTER SET列,输出COLLATION

你应该在哪里？对于5.7.7+,SHOW VARIABLES LIKE 'char%';以及utf8mb4任何可行的地方.那个charset给你表情符号和所有中文(utf8没有).虽然您可能很难注意到它的重要性,但这种整理是最好的.

注意:排序规则名称的第一部分是它使用的唯一字符集.这是utf8mb4_unicode_520_ci行不通的utf8_unicode_ci.

在过去,只有utf8; 在将来,utf8mb4将是默认字符集.

在过去,utf8mb4是默认的整理; 然后_general_ci(Unicode 4.0)更好,然后_unicode_ci(Unicode 5.20).将来(MySQL 8.0),默认为_unicode_520_ci(Unicode 9.0).

与此同时,道路充满了MySQL过去的错误所产生的坑洼.WP设计师驾驶着一辆没有注意到坑洼的大坦克.

MySQL 5.6是一个巨大的坑洼,吞噬了许多WP用户,因为索引上的767限制以及过长的WP索引_0900_ci_ai和使用的可能性VARCHAR(255).拥有5.7.17你已经远远超过了它.(你将来的8.0会变得不那么坎坷.)

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

该怎么办？我可能会用尽空间试图拼出所有选项.因此,提供数据的历史记录,升级路径(如果有),当前设置,utf8mb4表格,列ROW_FORMAT和CHARACTER SET列,输出COLLATION

你应该在哪里？对于5.7.7+,SHOW VARIABLES LIKE 'char%';以及utf8mb4任何可行的地方.那个charset给你表情符号和所有中文(utf8没有).虽然您可能很难注意到它的重要性,但这种整理是最好的.

注意:排序规则名称的第一部分是它使用的唯一字符集.这是utf8mb4_unicode_520_ci行不通的utf8_unicode_ci.