轉(zhuǎn)載自：
MySQL 的 collation
在以前用oracle的時候，很少關(guān)于它的collation方法，但是在mysql中爪飘，這點不加注意的話，卻有可能會出現(xiàn)問題拉背。
問題是這樣的：
一張test的表师崎，字符集采用的latin1。
select to_id from test where to_id='cn象王';
+---------------+
| to_id |
+---------------+
| cn陶陶 |
| cn象_王 |
+---------------+
2 rows in set (0.00 sec)
取cn象王的數(shù)據(jù),居然把cn陶陶的數(shù)據(jù)也取回來了椅棺。
這顯然是不允許的犁罩。
查看它們的編碼：
(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會認為這兩條記錄是一樣的呢两疚？
一開始我們就把問題定位于collation引起的問題床估。
show variables查看
| collation_connection | latin1_swedish_ci
| collation_database | latin1_swedish_ci
| collation_server | latin1_swedish_ci
手工把這些參數(shù)修改為latin1_bin，結(jié)果居然一樣诱渤。這下感覺真是奇怪了丐巫。
這里先解釋一下mysql collation的命名規(guī)則：
它們以其相關(guān)的字符集名開始，通常包括一個語言名勺美，并且以_ci（大小寫不敏感）递胧、_cs（大小寫敏感）或_bin（二元）結(jié)束
比如latin1字符集有以下幾種校正規(guī)則：
校對規(guī)則 含義
latin1_german1_ci 德國DIN-1
latin1_swedish_ci 瑞典/芬蘭
latin1_danish_ci 丹麥/挪威
latin1_german2_ci 德國 DIN-2
latin1_bin 符合latin1編碼的二進制
latin1_general_ci 多種語言(西歐)
latin1_general_cs 多種語言(西歐ISO),大小寫敏感
latin1_spanish_ci 現(xiàn)代西班牙
最后我們將表格重建，手工指定表格級別的collation為latin1_bin赡茸。
這個問題就得到了解決缎脾。
那么問題又來了，為什么我前面手工測試latin1_bin時不生效呢坛掠？
原來MySQL按照下面的方式選擇表字符集和 校對規(guī)則：
如果指定了CHARACTER SET X和COLLATE Y赊锚，那么采用CHARACTER SET X和COLLATE Y。
如果指定了CHARACTER SET X而沒有指定COLLATE Y屉栓，那么采用CHARACTER SET X和CHARACTER SET X的默認校對規(guī)則舷蒲。
否則，采用服務(wù)器字符集和服務(wù)器校對規(guī)則友多。
而我們在建表的時候指定了character set牲平，所以它永遠是采用對應(yīng)的默認的校對規(guī)則。
當然我們其實也沒必要重建表格域滥，只需要alter table db_allot CONVERT TO CHARACTER SET latin1 COLLATE latin1_bin這樣轉(zhuǎn)換即可纵柿。
另外建議collation都盡量采用字符集相應(yīng)的bin類型的校對規(guī)則蜈抓，這樣不容易出錯。
再說說我自己的體會
覺得 character set latin1 collate latin1_bin 就是老版的 VARCHAR BINARY 的改進昂儒，只是新版的先用 character set 定字符集沟使，再用此字符集名字加 _bin 定校對規(guī)則為二進制的，從而確保中文查詢正確渊跋。
再測試了一下腊嗡，把此字段屬性改為不帶 BINARY 的
ALTER TABLE comment_content_1_01 CHANGE thread thread VARCHAR( 50 ) DEFAULT NULL
然后再看表結(jié)構(gòu)確實變成 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
后客们，
再導出表結(jié)構(gòu)
CREATE TABLE comment_content_1_01 (
content_id int(11) NOT NULL auto_increment,
thread varchar(50) collate latin1_bin default NULL,
uname varchar(100) collate latin1_bin default NULL,
nick varchar(100) collate latin1_bin default NULL,
uid int(11) unsigned default NULL,
content text collate latin1_bin,
post_time datetime default NULL,
post_ip int(10) unsigned default NULL,
status enum('unaudit','normal','deleted') collate latin1_bin NOT NULL default 'unaudit',
PRIMARY KEY (content_id)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_bin;
即便原來沒定各字段的 collate，現(xiàn)在也全都是 collate latin1_bin 了材诽。
