用了这么长时间，发现本身居然不知道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数据了。