略懂MySQL字符集_MySQL

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