場景是這樣的嘱吗，小馬在搞一個類似匹配口令兌換獎勵的項(xiàng)目，比如類似淘口令整以，aaBbC兌換禮品 A禮包胧辽。最簡單的實(shí)現(xiàn)方式就是MySQL記錄口令碼和禮包映射，然后查詢匹配公黑。一切似乎看起來沒啥問題邑商，然而產(chǎn)品提出了一個問題，如果用AaBbC或者AABbC也能兌換成功帆调，說明MySQL的查詢語句是能匹配的奠骄。本質(zhì)上，如果業(yè)務(wù)允許這么兼容大小寫匹配也問題不大番刊，但是因?yàn)橐恍┢渌麊栴}的設(shè)置含鳞，比如根據(jù)口令碼緩存，那么就會很多的緩存key芹务，顯然不是很合理蝉绷。于是，就有了下面的分享枣抱。
mysql查詢不區(qū)分大小寫
小馬的語句大概如下：
select * from TableA? where? keyword= 'aaBbC';
于是把語句換成：
select * from TableA? where? keyword= 'AaBbC';
果然是匹配的熔吗，說明查詢條件對大小寫不敏感。那么是什么問題呢佳晶？也就是SQL默認(rèn)匹配字符集是不會區(qū)分大小寫的桅狠。
兩種解決方案
1、在SQL中使用BINARY
BINARY運(yùn)算符將緊隨其后的 string 轉(zhuǎn)換為二進(jìn)制字符串轿秧。
主要用來強(qiáng)制進(jìn)行按字節(jié)進(jìn)行比較(byte by byte),字節(jié)而不是字符的字符中跌。這使得字符串比較是區(qū)分大小寫的, 不管原始的列定義是否是 BINARY 或者 BLOB。BINARY 也對字符串末尾的空格敏感菇篡。
于是改后語句如下：
select * from TableA? where? binary keyword= 'aaBbC';
小馬親測可行漩符。但要注意此種解決方案中的SQL語法是否能被當(dāng)前項(xiàng)目的DB層識別，因?yàn)橛行┦荄B代理或者框架封裝的DB底層可能不認(rèn)識這個語法驱还。
2嗜暴、修改字段的字符集
ALTER? TABLE? TableA?? MODIFY? COLUMN? keyword? VARCHAR(50)? BINARY? CHARACTER? SET? utf8 COLLATE utf8_bin;
對于CHAR凸克、VARCHAR和TEXT類型，BINARY屬性可以為列分配該列字符集的 校對規(guī)則闷沥。
BINARY屬性是指定列字符集的二元 校對規(guī)則的簡寫萎战，排序和比較基于數(shù)值字符值。因此也就自然區(qū)分了大小寫狐赡。
問題來了撞鹉，如果直接設(shè)置成BINARY 類型呢，是不是也就直接支持了大小寫匹配颖侄？
