bitsCN.com
略懂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
行文至此、大意已明、后续想到、再续前缘
bitsCN.com
