select?distinct?*?from?prvt_pub_stmt_vnwhere?issue_time?&gt;=?'2020-08-01'and?issue_time?<p>我分析來分析去，感覺沒有問題呀，于是查了一下prs_dmtd_cde 字段的碼值，發現不僅有大寫的P還有小寫的p，而妹子只查了小寫的p，數據量卻多了很多。</p><p>于是我就把妹子的SQL改了一下：</p><pre class="brush:php;toolbar:false;">select?distinct?*?from?prvt_pub_stmt_vnwhere?issue_time?&gt;=?'2020-08-01'and?issue_time?<p>查出來的結果竟然是一樣的。這就。。。</p><p>在妹子面前當然不能說不行啊，于是讓妹子先回去再看看。</p><p>我這邊飛快的上網查了查，發現竟然是MySQL 的編碼格式和排序規則的問題。</p><h1 data-id="heading-1">知其所以然</h1><p>我們MySQL數據庫基本上用的都是 utf8 的編碼格式，而 utf8 編碼格式還存在各種排序規則。常用的如下：</p><p>utf8_bin：將字符串中的每一個字符以十六進制方式存儲數據，區分大小寫。</p><p>utf8_general_ci：不區分大小寫，ci為case insensitive的縮寫，即大小寫不敏感。</p><p>再查一下默認的字符集設置：</p><figure><img  class="lazyload" src="https://img.php.cn/upload/article/000/000/052/9f73450f4707fd4bcac7e0e9b5ff02e4-1.png" data-   style="max-width:90%" data- style="max-width:90%" alt="MySQL的where查詢的重新認識" ></figure><p>剛好 utf8 編碼格式的默認排序規則就是：utf8_general_ci——即不區分大小寫。</p><h1 data-id="heading-2">解決方案</h1><p>問題原因找到了，那就對癥下藥好了。</p><p>解決方法自然就是直接修改字段的 collate 屬性為 utf8_bin。</p><pre class="brush:php;toolbar:false;">ALTER?TABLE?prvt_pub_stmt_vn?CHANGE?prs_dmtd_cde?prs_dmtd_cde?VARCHAR(255)? CHARACTER?SET?utf8?COLLATE?utf8_bin;復制代碼

select?distinct?*?from?prvt_pub_stmt_vnwhere?issue_time?&gt;=?'2020-08-01'and?issue_time?<p>Mysql 默認查詢是不分大小寫的，可以在 SQL 語句中加入 binary 來區分大小寫。</p><p>binary 不是函數，是類型轉換運算符，它用來強制它后面的字符串為一個二進制字符串，可以理解為在字符串比較的時候區分大小寫。</p><h1 data-id="heading-3">最后</h1><p>問題解決了，當然是去告訴妹子這個問題多么多么深奧，我又是如何剖析原理最終解決的了。</p><p>看著妹子投來的崇拜目光，當然是很開心了。</p><p>最最重要的還是要記住這個問題，以后在遇到字段大小寫敏感的業務，建表的時候要注意字符集和排序規則的選擇，以避免今天這種事情的發生。</p><blockquote><p>想了解更多編程學習，敬請關注<a href="https://www.php.cn/" target="_blank">php培訓</a>欄目！<br></p></blockquote>