MySQL的where查询的从新相识
相关学习引荐:mysql教程
不克不及说不可
今天加班,业务的妹子过来寻我们查数据,说数据查出来量不合错误。一看妹子的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 的编码格局和排序规则的问题。
知其所以然
我们MySQL数据库根本上用的都是 utf8 的编码格局,而 utf8 编码格局还存在各种排序规则。常用的如下:
utf8_bin:将字符串中的每一个字符以十六进制方式储备数据,区分大小写。
utf8_general_ci:不区分大小写,ci为case insensitive的缩写,即大小写不敏锐。
再查一下默许的字符集设定:
![](/uploads/allimg/200930/9f73450f4707fd4bcac7e0e9b5ff02e4-117099.png)
恰好 utf8 编码格局的默许排序规则就是:utf8_general_ci——即不区分大小写。
解决方案
问题缘由寻到了,那就有的放矢好了。
解决办法天然就是直接修改字段的 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 不是函数,是类型转换运算符,它用来强迫它后面的字符串为一个二进制字符串,可以懂得为在字符串比力的时候区分大小写。
最后
问题解决了,当然是去告诉妹子这个问题多么多么深奥,我又是怎样分析道理终究解决的了。
看着妹子投来的崇敬目光,当然是很快乐了。
最最重要的还是要记住这个问题,今后在碰到字段大小写敏锐的业务,建表的时候要留意字符集和排序规则的选中,以幸免今天这种事情的发生。