略懂 MySQL字元集

     本文雖說旨在明白、但若略懂亦可、畢竟諸葛孔明如是
     只有基於字元的值才有所謂字元集的概念
     某些字元集可能需要更多CPU、消費更多的記憶體和磁碟空間、甚至影響索引使用
     這還不包括令人蛋碎的亂碼、
     可見、我們還是有必要花點時間略懂下MySQL字元集
     

     先直觀認識各階梯下顯示使用字元集：

# 囊括三個層級：DB、Table、Columnmysql> 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

     行文至此、大意已明、後續想到、再續前緣

By WaterBin

2013-07-18

Good LUck