今天加班，业务的妹子过来找我们查数据，说数据查出来量不对。一看妹子的SQL是这样写的：
selectdistinct*fromprvt_pub_stmt_vnwhereissue_time>='2020-08-01'andissue_time<='2020-08-01'andprs_dmtd_cdein('p','n');
我分析来分析去，感觉没有问题呀，于是查了一下prs_dmtd_cde 字段的码值，发现不仅有大写的P还有小写的p，而妹子只查了小写的p，数据量却多了很多。
于是我就把妹子的SQL改了一下：
selectdistinct*fromprvt_pub_stmt_vnwhereissue_time>='2020-08-01'andissue_time<='2020-08-01'andprs_dmtd_cdein('p','n','P','N');
查出来的结果竟然是一样的。这就。。。
在妹子面前当然不能说不行啊，于是让妹子先回去再看看。
我这边飞快的上网查了查，发现竟然是MySQL 的编码格式和排序规则的问题。
我们MySQL数据库基本上用的都是 utf8 的编码格式，而 utf8 编码格式还存在各种排序规则。常用的如下：
utf8_bin：将字符串中的每一个字符以十六进制方式存储数据，区分大小写。
utf8_general_ci：不区分大小写，ci为case insensitive的缩写，即大小写不敏感。
再查一下默认的字符集设置：
刚好 utf8 编码格式的默认排序规则就是：utf8_general_ci——即不区分大小写。
解决方案
问题原因找到了，那就对症下药好了。
解决方法自然就是直接修改字段的 collate 属性为 utf8_bin。
ALTERTABLEprvt_pub_stmt_vnCHANGEprs_dmtd_cdeprs_dmtd_cdeVARCHAR(255)CHARACTERSETutf8COLLATEutf8_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 不是函数，是类型转换运算符，它用来强制它后面的字符串为一个二进制字符串，可以理解为在字符串比较的时候区分大小写。
最后
问题解决了，当然是去告诉妹子这个问题多么多么深奥，我又是如何剖析原理最终解决的了。
看着妹子投来的崇拜目光，当然是很开心了。
最最重要的还是要记住这个问题，以后在遇到字段大小写敏感的业务，建表的时候要注意字符集和排序规则的选择，以避免今天这种事情的发生。
产品猿社区致力收录更多优质的商业产品，给服务商以及软件采购客户提供更多优质的软件产品，帮助开发者变现来实现多方共赢；
日常运营的过程中我们难免会遇到各种版权纠纷等问题，如果您在社区内发现有您的产品未经您授权而被用户提供下载或使用，您可按照我们投诉流程处理，点我投诉；
本文来自用户发布投稿，不代表产品猿立场 ；若对此文有疑问或内容有严重错误，可联系平台客服反馈；
部分产品是用户投稿，可能本文没有提供官方下下载地址或教程，若您看到的内容没有下载入口，您可以在我们产品园商城搜索看开发者是否有发布商品；若您是开发者，也诚邀您入驻商城平台发布的产品，地址：点我进入；
如若转载，请注明出处：https://www.chanpinyuan.cn/42622.html；
