mysql区分大小写设置_MySQL的where查询不区分字段大小写!!!

6ae5a397d6af011d87c8d4ebd1d12ab7.png        

不能说不行

今天加班,业务的妹子过来找我们查数据,说数据查出来量不对。一看妹子的SQL是这样写的:

select distinct * from prvt_pub_stmt_vnwhere issue_time >= '2020-08-01'and issue_time <= '2020-08-01'and prs_dmtd_cde in ('p','n');

我分析来分析去,感觉没有问题呀,于是查了一下prs_dmtd_cde 字段的码值,发现不仅有大写的P还有小写的p,而妹子只查了小写的p,数据量却多了很多。

于是我就把妹子的SQL改了一下:

select distinct * from prvt_pub_stmt_vnwhere issue_time >= '2020-08-01'and issue_time <= '2020-08-01'and prs_dmtd_cde in ('p','n','P','N');

查出来的结果竟然是一样的。这就。。。

在妹子面前当然不能说不行啊,于是让妹子先回去再看看。

我这边飞快的上网查了查,发现竟然是MySQL 的编码格式和排序规则的问题。

6ae5a397d6af011d87c8d4ebd1d12ab7.png        

知其所以然

我们MySQL数据库基本上用的都是 utf8 的编码格式,而 utf8 编码格式还存在各种排序规则。常用的如下:

  1. utf8_bin:将字符串中的每一个字符以十六进制方式存储数据,区分大小写。

  2. utf8_general_ci:不区分大小写,ci为case insensitive的缩写,即大小写不敏感

再查一下默认的字符集设置:

8039a6e83f078837f09ab25c15b2eddd.png

刚好 utf8 编码格式的默认排序规则就是:utf8_general_ci——即不区分大小写。

6ae5a397d6af011d87c8d4ebd1d12ab7.png        

解决方案

问题原因找到了,那就对症下药好了。

解决方法自然就是直接修改字段的 collate 属性为 utf8_bin。

ALTER TABLE prvt_pub_stmt_vn CHANGE prs_dmtd_cde prs_dmtd_cde VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_bin;

另外还看到另一种解决方法,就是不改变原有表结构,而是改SQL。在查询字段前加上 binary 关键字。

select distinct * from prvt_pub_stmt_vnwhere issue_time >= '2020-08-01'and issue_time <= '2020-08-01'and binary prs_dmtd_cde in ('p','n');

Mysql 默认查询是不分大小写的,可以在 SQL 语句中加入 binary 来区分大小写。

binary 不是函数,是类型转换运算符,它用来强制它后面的字符串为一个二进制字符串,可以理解为在字符串比较的时候区分大小写。

6ae5a397d6af011d87c8d4ebd1d12ab7.png        

最后

问题解决了,当然是去告诉妹子这个问题多么多么深奥,我又是如何剖析原理最终解决的了。

看着妹子投来的崇拜目光,当然是很开心了。

最最重要的还是要记住这个问题,以后在遇到字段大小写敏感的业务,建表的时候要注意字符集和排序规则的选择,以避免今天这种事情的发生。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值