select to_id from test where to_id='cn象_王'; +---------------+ | to_id | +---------------+ | cn陶_陶 | | cn象_王 | +---------------+ 2 rows in set (0.00 sec)
取cn象_王的数据,居然把cn陶_陶的数据也取回来了。 这显然是不允许的。
查看它们的编码:
(root@im_offlog1a)[test]> select hex('cn陶_陶'); +----------------+ | hex('cn陶_陶') | +----------------+ | 636ECCD55FCCD5 | +----------------+ 1 row in set (0.00 sec)
(root@im_offlog1a)[test]> select hex('cn象_王'); +----------------+ | hex('cn象_王') | +----------------+ | 636ECFF35FCDF5 | +----------------+ 1 row in set (0.00 sec)
原来MySQL按照下面的方式选择表字符集和 校对规则: 如果指定了CHARACTER SET X和COLLATE Y,那么采用CHARACTER SET X和COLLATE Y。 如果指定了CHARACTER SET X而没有指定COLLATE Y,那么采用CHARACTER SET X和CHARACTER SET X的默认校对规则。 否则,采用服务器字符集和服务器校对规则。
而我们在建表的时候指定了character set,所以它永远是采用对应的默认的校对规则。
当然我们其实也没必要重建表格,只需要alter table db_allot CONVERT TO CHARACTER SET latin1 COLLATE latin1_bin这样转换即可。
另外建议collation都尽量采用字符集相应的bin类型的校对规则,这样不容易出错。
再说说我自己的体会
觉得 character set latin1 collate latin1_bin 就是老版的 VARCHAR BINARY 的改进,只是新版的先用 character set 定字符集,再用此字符集名字加 _bin 定校对规则为二进制的,从而确保中文查询正确。 再测试了一下,把此字段属性改为不带 BINARY 的 ALTER TABLE `comment_content_1_01` CHANGE `thread` `thread` VARCHAR( 50 ) DEFAULT NULL 然后再看表结构确实变成 `thread` varchar(50) default NULL, 即不带 character set latin1 collate latin1_bin 了,可见character set latin1 collate latin1_bin 就是老版的 VARCHAR BINARY 的改进。
此外还读到更方便的做法,不用逐个改字段属性,而只要表格级别的collation为latin1_bin就行了。 测试: alter table comment_content_1_01 CONVERT TO CHARACTER SET latin1 COLLATE latin1_bin 后,