hi,你好!欢迎访问本站!登录
本站由网站地图腾讯云宝塔系统阿里云强势驱动
当前位置:首页 - 教程 - 数据库 - 正文 君子好学,自强不息!

MySQL的where查询的重新认识_数据库

2020-09-15数据库搜奇网4°c
A+ A-

相干进修引荐: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的缩写,即大小写不敏感。

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

恰好 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 不是函数,是范例转换运算符,它用来强迫它背面的字符串为一个二进制字符串,能够理解为在字符串比较的时刻辨别大小写。

末了

问题处理了,固然是去通知妹子这个问题何等何等深邃,我又是怎样理会道理终究处理的了。

看着妹子投来的崇敬眼光,固然是很高兴了。

最最主要的照样要记着这个问题,今后在碰到字段大小写敏感的营业,建表的时刻要注意字符集和排序划定规矩的挑选,以防止本日这类事变的发作。

想相识更多编程进修,敬请关注php培训栏目!

以上就是MySQL的where查询的重新认识的细致内容,更多请关注ki4网别的相干文章!

  选择打赏方式
微信赞助

打赏

QQ钱包

打赏

支付宝赞助

打赏

  移步手机端
MySQL的where查询的重新认识_数据库

1、打开你手机的二维码扫描APP
2、扫描左则的二维码
3、点击扫描获得的网址
4、可以在手机端阅读此文章
标签:

本文来源:搜奇网

本文地址:https://www.sou7.cn/300738.html

关注我们:微信搜索“搜奇网”添加我为好友

版权声明: 本文仅代表作者个人观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。请记住本站网址https://www.sou7.cn/搜奇网。