Mysql中的排序規矩utf8_unicode_ci、utf8_general_ci的差別總結。本站提示廣大學習愛好者：（Mysql中的排序規矩utf8_unicode_ci、utf8_general_ci的差別總結）文章只能為提供參考，不一定能成為您想要的結果。以下是Mysql中的排序規矩utf8_unicode_ci、utf8_general_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、具體總結
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便可以了
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數據了。
