本篇文章給大家帶來的內容是關于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:字符串每個字符串用二進制數據編譯存儲。 區分大小寫，而且可以存二進制的內容
一、官方文檔說明
下面摘錄一下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;
二、簡短總結
utf8_unicode_ci和utf8_general_ci對中、英文來說沒有實質的差別。
utf8_general_ci校對速度快，但準確度稍差。
utf8_unicode_ci準確度高，但校對速度稍慢。
如果你的應用有德語、法語或者俄語，請一定使用utf8_unicode_ci。一般用utf8_general_ci就夠了，到現在也沒發現問題。。。
三、詳細總結
1、對于一種語言僅當使用utf8_unicode_ci排序做的不好時，才執行與具體語言相關的utf8字符集校對規則。例如，對于德語和法語，utf8_unicode_ci工作的很好，因此不再需要為這兩種語言創建特殊的utf8校對規則。
2、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就可以了
四、如何在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?<p>大功告成！！</p><p>附2：支持查看utf8字符集的MySQL客戶端有<br>1.) MySQL-Front，據說這個項目已經被MySQL AB勒令停止了，不知為何，如果國內還有不少破解版可以下載（不代表我推薦使用破解版 :-P）。<br>2.) Navicat，另一款非常不錯的MySQL客戶端，漢化版剛出來，還邀請我試用過，總的來說還是不錯的，不過也需要付費。<br>3.) PhpMyAdmin，開源的php項目，非常好。<br>4.) Linux下的終端工具（Linux terminal），把終端的字符集設置為utf8，連接到MySQL之后，執行 SET NAMES UTF8; 也能讀寫utf8數據了。</p><p>本篇文章到這里就已經全部結束了，更多其他精彩內容可以關注PHP中文網的<a href="http://www.php.cn/course/list/51.html" target="_blank">MySQL視頻教程</a>欄目！</p><p class="clearfix"><span id="art_bot" class="jbTestPos"></span></p>
