由于项目环境的缘故， 在java项目中使用了ibatis， 而ibatis已经有个数据源是ascii (iso8859)编码，因此mysql 数据库必须使用latin1编码， mysql客户端库也使用latin1编码，正常情况下，使用都正常，但发现有几个数据很奇怪，如只过滤"淘_淘"的数据，结果把"象_王"的数据查了出来， 和DBA一起搞了半天，使用hex函数查看"淘_淘"和"象_王"的ascii值也是不同的， 换成GBK编码，结果是好的，可以区分"象_王"和"淘_淘"， 说明是编码问题， 这样就是查看编码，使用 show variables like 'character%'; 结果是:
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
说明编码没问题， 这就奇怪了，再查看mysql文档，发现还有一个校对集的概念，是不是校对集的问题，使用 show variables like 'colla%'; 查看，结果如下:
+----------------------+-------------------+
| Variable_name | Value |
+----------------------+-------------------+
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
+----------------------+-------------------+
也是 latin1， 但对 latin1_swedish_ci 不是很理解，查看文档后得知，是瑞典的不区分大小写的编码， 因此估计是这个校对集的缘故，将校对集转换成 latin1_bin 解决问题：
alter table xxx convert (latin1_swedish_ci,latin1_bin)
最好的解决方法是创建数据库时指定编码：
create database dbtest DEFAULT CHARACTER SET latin1 COLLATE latin1_bin;
或创建表的时候指定：
create table tbtest(name varchar(40) primary key, val varchar(1000)) ENGINE = InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin; |
