平时非常少会考虑数据存储须要明白字符串类型字段的大写和小写，MySQL默认的查询也不区分大写和小写。但作为用户信息。一旦username反复，又会浪费非常多资源。再者，李逵、李鬼的多起来。侦辨起来非常困难。

要做到这一点，要么在建表时。明白大写和小写敏感（字段明白大写和小写敏感）。

假设通盘数据库全部字段都须要大写和小写敏感。不如在字符集设置时做好调整。只是，通常不建议这么做。
 
假设跟我一样。数据库已经在线上跑了，一个表上百万条数据。做字段类型变更有可能导致数据库宕机。

那么好吧，在查询时，多加个单词好了。
比如，一般查询：

SELECT * FROM `user` WHERE name LIKE 'a%';  
SELECT * FROM `user` WHERE name LIKE 'A%';

其结果是一样的，为了区分'A%'和'a%'。能够这么做：


  


SELECT * FROM `user` WHERE binary name LIKE 'a%';  
SELECT * FROM `user` WHERE binary name LIKE 'A%';

只多了一个binary，就能够得到不同的结果。


 


当然，假设须要建表时强制区分大写和小写，能够这么写： 


create  table  `user`(    
     name varchar (20) binary      
);


转载于:




平时非常少会考虑数据存储须要明白字符串类型字段的大写和小写，MySQL默认的查询也不区分大写和小写。但作为用户信息。一旦username反复，又会浪费非常多资源。再者，李逵、李鬼的多起来。侦辨起来非常困难。

要做到这一点，要么在建表时。明白大写和小写敏感（字段明白大写和小写敏感）。

假设通盘数据库全部字段都须要大写和小写敏感。不如在字符集设置时做好调整。只是，通常不建议这么做。
 
假设跟我一样。数据库已经在线上跑了，一个表上百万条数据。做字段类型变更有可能导致数据库宕机。

那么好吧，在查询时，多加个单词好了。
比如，一般查询：

SELECT * FROM `user` WHERE name LIKE 'a%';  
SELECT * FROM `user` WHERE name LIKE 'A%';

其结果是一样的，为了区分'A%'和'a%'。能够这么做：


  


SELECT * FROM `user` WHERE binary name LIKE 'a%';  
SELECT * FROM `user` WHERE binary name LIKE 'A%';

只多了一个binary，就能够得到不同的结果。


 


当然，假设须要建表时强制区分大写和小写，能够这么写： 


create  table  `user`(    
     name varchar (20) binary      
);