【轉】Mysql中的排序規則utf8_unicode_ci、utf8_general_ci的區別總結

Mysql中utf8_general_ci與utf8_unicode_ci有什麼區別呢？在編程語言中，一般用unicode對中文字符作處理，防止出現亂碼，那麼在MySQL裏，爲何你們都使用utf8_general_ci而不是utf8_unicode_ci呢？

 

用了這麼長時間，發現本身居然不知道utf_bin和utf_general_ci這二者到底有什麼區別。。
ci是 case insensitive, 即 "大小寫不敏感", a 和 A 會在字符判斷中會被當作同樣的;
bin 是二進制, a 和 A 會別區別對待.
例如你運行:
SELECT * FROM table WHERE txt = 'a'
那麼在utf8_bin中你就找不到 txt = 'A' 的那一行, 而 utf8_general_ci 則能夠.
utf8_general_ci 不區分大小寫，這個你在註冊用戶名和郵箱的時候就要使用。
utf8_general_cs 區分大小寫，若是用戶名和郵箱用這個 就會照成不良後果
utf8_bin:字符串每一個字符串用二進制數據編譯存儲。 區分大小寫，並且能夠存二進制的內容

1、官方文檔說明
下面摘錄一下Mysql 5.1中文手冊中關於utf8_unicode_ci與utf8_general_ci的說明：

複製代碼代碼以下:

     當前，utf8_unicode_ci校對規則僅部分支持Unicode校對規則算法。一些字符仍是不能支持。而且，不能徹底支持組合的記號。這主要影響越南和俄羅斯的一些少數民族語言，如：Udmurt 、Tatar、Bashkir和Mari。

 

     utf8_unicode_ci的最主要的特點是支持擴展，即當把一個字母看做與其它字母組合相等時。例如，在德語和一些其它語言中‘ß'等於‘ss'。

     utf8_general_ci是一個遺留的 校對規則，不支持擴展。它僅可以在字符之間進行逐個比較。這意味着utf8_general_ci校對規則進行的比較速度很快，可是與使用utf8_unicode_ci的 校對規則相比，比較正確性較差）。

     例如，使用utf8_general_ci和utf8_unicode_ci兩種 校對規則下面的比較相等：
     Ä = A
     Ö = O
     Ü = U

     兩種校對規則之間的區別是，對於utf8_general_ci下面的等式成立：
     ß = s

     可是，對於utf8_unicode_ci下面等式成立：
     ß = ss

     對於一種語言僅當使用utf8_unicode_ci排序作的很差時，才執行與具體語言相關的utf8字符集 校對規則。例如，對於德語和法語，utf8_unicode_ci工做的很好，所以再也不須要爲這兩種語言建立特殊的utf8校對規則。

     utf8_general_ci也適用與德語和法語，除了‘ß'等於‘s'，而不是‘ss'以外。若是你的應用可以接受這些，那麼應該使用utf8_general_ci，由於它速度快。不然，使用utf8_unicode_ci，由於它比較準確。

若是你想使用gb2312編碼,那麼建議你使用latin1做爲數據表的默認字符集,這樣就能直接用中文在命令行工具中插入數據,而且能夠直接顯示出來.而不要使用gb2312或者gbk等字符集,若是擔憂查詢排序等問題,可使用binary屬性約束,例如:

複製代碼代碼以下:

create table my_table ( name varchar(20) binary not null default '')type=myisam default charset latin1;

 

2、簡短總結
utf8_unicode_ci和utf8_general_ci對中、英文來講沒有實質的差異。
utf8_general_ci校對速度快，但準確度稍差。
utf8_unicode_ci準確度高，但校對速度稍慢。

若是你的應用有德語、法語或者俄語，請必定使用utf8_unicode_ci。通常用utf8_general_ci就夠了，到如今也沒發現問題。。。

3、詳細總結

一、對於一種語言僅當使用utf8_unicode_ci排序作的很差時，才執行與具體語言相關的utf8字符集校對規則。例如，對於德語和法語，utf8_unicode_ci工做的很好，所以再也不須要爲這兩種語言建立特殊的utf8校對規則。
二、utf8_general_ci也適用與德語和法語，除了‘?'等於‘s'，而不是‘ss'以外。若是你的應用可以接受這些，那麼應該使用 utf8_general_ci，由於它速度快。不然，使用utf8_unicode_ci，由於它比較準確。

用一句話概況上面這段話：utf8_unicode_ci比較準確，utf8_general_ci速度比較快。一般狀況下 utf8_general_ci的準確性就夠咱們用的了，在我看過不少程序源碼後，發現它們大多數也用的是utf8_general_ci，因此新建數據 庫時通常選用utf8_general_ci就能夠了

4、如何在MySQL5.0中使用UTF8
在 my.cnf中增長下列參數

複製代碼代碼以下:

[mysqld]
init_connect='SET NAMES utf8′
default-character-set=utf8
default-collation = utf8_general_ci

 

執行查詢 mysql> show variables; 相關以下: 

複製代碼代碼以下:

character_set_client | utf8 
character_set_connection | utf8 
character_set_database | utf8 
character_set_results | utf8 
character_set_server | utf8 
character_set_system | utf8

 

collation_connection | utf8_general_ci 
collation_database | utf8_general_ci 
collation_server | utf8_general_ci

 

我的看法，對於數據庫的使用，utf8 - general 已經足夠的準確，而且相較與  utf8 - unicode速度上有優點，固可放心採用之

附1：舊數據升級辦法
以原來的字符集爲latin1爲例，升級成爲utf8的字符集。原來的表: old_table (default charset=latin1)，新表：new_table(default charset=utf8)。
第一步：導出舊數據

複製代碼代碼以下:

mysqldump --default-character-set=latin1 -hlocalhost -uroot -B my_db --tables old_table > old.sql

第二步：轉換編碼(相似unix/linux環境下)

複製代碼代碼以下:

iconv -t utf-8 -f gb2312 -c old.sql > new.sql

或者能夠去掉 -f 參數，讓iconv自動判斷原來的字符集

複製代碼代碼以下:

iconv -t utf-8 -c old.sql > new.sql

在這裏，假定原來的數據默認是gb2312編碼。
第三步：導入
修改old.sql，在插入/更新語句開始以前，增長一條sql語句： "SET NAMES utf8;"，保存。

複製代碼代碼以下:

mysql -hlocalhost -uroot my_db < new.sql

大功告成！！

 

附2：支持查看utf8字符集的MySQL客戶端有1.) MySQL-Front，聽說這個項目已經被MySQL AB勒令中止了，不知爲什麼，若是國內還有很多破解版能夠下載（不表明我推薦使用破解版 :-P）。2.) Navicat，另外一款很是不錯的MySQL客戶端，漢化版剛出來，還邀請我試用過，總的來講仍是不錯的，不過也須要付費。3.) PhpMyAdmin，開源的php項目，很是好。4.) Linux下的終端工具（Linux terminal），把終端的字符集設置爲utf8，鏈接到MySQL以後，執行 SET NAMES UTF8; 也能讀寫utf8數據了。