略懂MySQL字符集_MySQL

略懂MySQL字符集

本文虽说旨在明白、但若略懂亦可、毕竟诸葛孔明如是

只有基于字符的值才有所谓字符集的概念

某些字符集可能需要更多CPU、消费更多的内存和磁盘空间、甚至影响索引使用

这还不包括令人蛋碎的乱码、

可见、我们还是有必要花点时间略懂下MySQL字符集

先直观认识各阶梯下显示使用字符集：

[sql] # 囊括三个层级：DB、Table、Column    mysql> create database d charset utf8;  Query OK, 1 row affected (0.04 sec)    mysql> create table d.t      -> (str varchar(10) charset latin1)      -> default charset=utf8;  Query OK, 0 rows affected (0.05 sec)  

那如果没有显示指定？MySQL是如何设置？路分两条：

① 创建对象时的默认设置

这是个逐层继承的默认设置：

Server → DB → Table → Column

高层为底层设置默认值、底层可遵可弃、

没有指定字符集、谓之可遵

显示指定字符集、谓之可弃

② 服务器和客户端通信时的设置

当客户端提交一条SQL到MySQL时、MySQL Server总是假定客户端字符集是character_set_client

其后、Server把character_set_client转为character_set_connection进行SQL处理、

在返回结果集给客户端时、Server又将character_set_connection转为character_set_result、然后返回

以上涉及的三个字符集、我们可以通过set names 一次搞定

字符集之间的相互转换是需要额外的系统开销的、

如何知道？

explain extended + show warnings 即可

那该如何尽量避免这种隐式转换？

这里介绍一种被称为"极简原则"的方法、如下：

先为服务器(或数据库)选择合适的字符集、然后依据业务、让某些列选择合适的字符集

在MySQL字符集中隐含了些意外惊喜、主要有三：

① 有趣的character_set_database

当character_set_database和character_set_server不同时、库的默认字符集由后者决定

你不能直接修改csd、改变css就改变了csd、因为csd和库默认字符集相同、

改变库默认字符集、csd就随之改变、而css决定库的默认字符集

所以、当连接到mysql实例、又没有指定库时、默认字符集与css相同

② load data infile

进行此操作时、建议最佳实践如下：

use 库;

set names 字符集;

开始加载数据；

这就使用统一字符集、避免混搭的"字符集style"

③ select into outfile

该行为没有进行任何转码操作！

有人说、不管37二十一、全用utf8、整个世界都清净了

但这不仅消耗更多磁盘空间、也带来一定性能牺牲

为什么？因为utf8是多字节字符集、比如一个汉字是三个字节

这会带来两方面的问题：

① 浪费空间、如char(10)可能会开辟30字节空间、即使不需要

② 索引长度限制、mysql总是假定一个字符三个字节、导致最长索引长度变成1/3

行文至此、大意已明、后续想到、再续前缘