略懂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
行文至此、大意已明、後續想到、再續前緣