容易被忽视的MySQL字符集问题？

在使用MySQL客户端书写SQL语句的时候，我们可以在字符串前边加 _charset_name 的符号，其中的 charset_name 对应着某个具体的字符集，废话不多说，先写两个例子看一下：

mysql> SELECT _utf8'我';
+-----+
| 我  |
+-----+
| 我  |
+-----+
1 row in set (0.04 sec)

mysql> SELECT _gbk'我';
+-----+
| 鎴  |
+-----+
| 鎴  |
+-----+
1 row in set, 1 warning (0.02 sec)

可以看到第一个查询结果正常，第二个查询出现了乱码。 为什么呢？ 下边细细道来。

原因

我们知道MySQL是一个 C/S 架构的软件，可以有很多客户端连接到服务器进行交互。 客户端发送给服务器的请求以及服务器发送给客户端的响应本质上都是一个二进制的字节串，每当我们从客户端发送一个请求到服务器，服务器处理完成之后再把响应返回给客户端的过程其实发生了很多字符集转换过程。

• 首先请求会被MySQL客户端编码为字节序列之后通过网络传输到服务器。

  对于MySQL自带的客户端来说，这个编码过程使用的字符集和我们使用的操作系统的默认字符集是一样的，类Unix系统的默认字符集就是 utf8 ，Windows系统的默认字符集就是 gbk 。

• 服务器收到字节序列请求之后，会认为该字节串是按照 character_set_client 系统变量编码的，之后将其从 character_set_client 转换到 character_set_connection ，之后进行更深入的处理。

• 最后再将响应发送到客户端的时候，又会按照 character_set_results 进行编码。

• 客户端收到响应字节串之后，按照本客户端规定的字符集进行解码。

  对于MySQL自带的客户端来说，这个解码过程使用的字符集和我们使用的操作系统的默认字符集是一样的，类Unix系统的默认字符集就是 utf8 ，Windows系统的默认字符集就是 gbk 。

总结一下这几个涉及到的通信字符集系统变量：

现在我的系统中的这几个系统变量的值都是 utf8 ：

mysql> SHOW VARIABLES LIKE 'character_set_client';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| character_set_client | utf8  |
+----------------------+-------+
1 row in set (0.24 sec)

mysql> SHOW VARIABLES LIKE 'character_set_connection';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| character_set_connection | utf8  |
+--------------------------+-------+
1 row in set (0.25 sec)

mysql> SHOW VARIABLES LIKE 'character_set_results';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| character_set_results | utf8  |
+-----------------------+-------+
1 row in set (0.30 sec)

如果我们使用了 _charset_name 前缀，意味着禁止服务器将后续字节从 character_set_client 转换到 character_set_connection ，而是默认使用 _charset_name 代表的字符集作为它后续字节的字符集。 比方说：

mysql> SELECT _gbk'我';
+-----+
| 鎴  |
+-----+
| 鎴  |
+-----+
1 row in set, 1 warning (0.02 sec)

我现在使用的是 macOS 操作系统，所以

• 客户端发送请求时会将字符’我’按照 utf8 进行编码，也就是： 0xE68891 。

• 服务器收到请求后发现有前缀 _gbk ，则不会将其后边的字节 0xE68891 进行从 character_set_client 到 character_set_connection 的转换，而是直接把 0xE68891 认为是某个字符串由 gbk 编码后得到的字节序列。

• 然后再把上述 0xE68891 从 gbk 转换为 character_set_results ，也就是 utf8 。 0xE688 在 gbk 中代表汉字 '鎴' ，而 0x91 无法解码（我们可以看到上述查询结果中有1个warning）。

  我们紧接着上边的查询语句执行一下 SHOW WARNINGS ：

  mysql> SHOW WARNINGS\G
  *************************** 1. row ***************************
    Level: Warning
     Code: 1300
  Message: Invalid gbk character string: '91'
  1 row in set (0.01 sec)
  

  之后将汉字 '鎴' 再按照 utf8 进行编码，得到的结果就是 E98EB4 ，把它发送到客户端。

• 客户端收到之后再解码到屏幕上，解码也使用 utf8 字符集，所以就出现了 鎴 。

扩展

如果在我的机器上我执行 SELECT LENGTH(_gbk '我') 会得到什么结果呢（LENGTH函数用来统计某个字符串共占用多少字节）？ 有 很多小伙伴不经思考，脱口而出： 2 !哈哈，我们看一下结果验证一下：

mysql> SELECT LENGTH(_gbk '我');
+--------------------+
| LENGTH(_gbk '我')  |
+--------------------+
|                  3 |
+--------------------+
1 row in set, 1 warning (0.01 sec)

WTH?竟然是3？ 其实再回想一下我们上边所说的，因为’我’前边加了 _gbk ，所以不会经历从 character_set_client 到 character_set_connection 的转换过程，而是直接把 0xE68891 当作是一个采用 gbk 编码的字节串。 这个字节串中有3个字节，当然结果就返回3了（虽然0x91这个字节在gbk字符集中是无效的，可以看到上边查询语句中也给出了Warning）。

思考

如果我现在不使用基于 macOS 操作系统的客户端，而采用基于 Windows 操作系统的客户端来发送请求，那么下边的语句的返回结果将会是什么呢：

SELECT LENGTH(_utf8 '我');

小青蛙历史文章（历史文章，不容错过）：

MySQL介于普通读和锁定读的加锁方式

关于事务和锁的一些细节

个人所得税涨了，日子又拮据了一点

补数到底是个什么玩意儿？从根儿上理解一下

虚拟内存是个啥 | 一分钟系列

MySQL中IS NULL、IS NOT NULL、!=不能用索引？胡扯！

长按关注小青蛙，都是干货喔

原文链接为《MySQL是怎样运行的： 从根儿上理解MySQL》小册链接