mysql设置字符集后不提交更改答案

【问题标题】：Mysql does not commit changes after setting character setmysql设置字符集后不提交更改
【发布时间】：2019-06-29 02:18:11
【问题描述】：

在我使用mysql -u root -p 登录到 MySQL 之后，我尝试使用set character_set_server = utf8;（它最初是 utf8mb4）设置字符集服务器（我还尝试了另一个用户，并且还使用--database 指定了一个数据库）。运行set 命令后，我使用show variables like "%charac%" 检查了变量。它将正确的值显示为 utf8。但是，在我退出会话并重新登录并重新检查变量后，它显示 utf8mb4。我还尝试在设置字符集后运行commit;，同样它没有改变值。我该怎么办？

【问题讨论】：

为什么要“降级”字符集？

标签： mysql collation character-set

【解决方案1】：

您尝试做的不是交易。事务与 DML（数据修改语言）语句（如 select、insert、upate、delete）一起使用。因此，在这里提交不是正确的做法。

大多数变量都有一个全局值和一个仅对当前会话有效的值。您可以在手册here 中看到这一点（查看scope）。当您未指定要更改全局值时，将假定会话值。

试试

set global character_set_server = 'utf8';

将该更改也添加到您的etc/my.cnf [mysqld] 部分下。否则，当你重新启动 mysql 服务器 (mysqld) 时，此更改将再次丢失。

最后，您可能希望将其保留在 uft8mb4。您可能会认为，您不需要额外的字节，但请记住，仅当您在文本中真正使用像表情符号这样的字符时，才会使用额外的字节。并且在性能方面它实际上表现更好。我手头没有证据，但我最近参加了一个数据库会议，其中一个演讲是关于基准检查的。它在那里说，它的表现要好得多。之前实现的utf8是残缺的utf8，应该尽快死掉。

【讨论】：

可能会议引用的是 utf8mb4 性能在 MySQL 8.0 中得到了显着的改进。（至少，我是这么听的。）
是的，你是对的，在 MySQL 8.0 中，但它的性能也比 utf8 好。应该澄清更多。谢谢。
至于“尽快死去”——我完全同意。我在这个网站上的大部分“声誉”来自于对 Emoji、767 索引限制、Mojibake 等方面的帮助。