由于项目环境的缘故, 在java项目中使用了ibatis, 而ibatis已经有个数据源是aiscii (iso8859)编码,因此mysql 数据库必须使用latin1编码, mysql客户端库也使用latin1编码,正常情况下,使用都正常,但发现有几个数据很奇怪,如只过滤”淘_淘”的数据,结果把”象_王”的数据查了出来, 和DBA一起搞了半天,使用hex函数查看”淘_淘”和”象_王”的ascii值也是不同的, 换成GBK编码,结果是好的,可以区分

“象_王”和”淘_淘”, 说明是编码问题, 这样就是查看编码,使用show variables like ‘colla%’; 结果是:

————————–+—————————-+
| 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/ |

说明编码没问题, 这就奇怪了,根据oracle的经验无法解释,再查看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;