MySQL的where查詢的重新認識

相關學習推薦：mysql教學

#不能說不行

今天加班，業務的女生來找我們查數據，說數據查出來量不對。一看妹子的SQL是這樣寫的：

select distinct * from prvt_pub_stmt_vnwhere issue_time >= &#39;2020-08-01&#39;and issue_time <= &#39;2020-08-01&#39;and prs_dmtd_cde in (&#39;p&#39;,&#39;n&#39;);复制代码

我分析來分析去，感覺沒有問題呀，於是查了一下prs_dmtd_cde 字段的碼值，發現不僅有大寫的P還有小寫的p，而妹子只查了小寫的p，資料量卻多了許多。

於是我就把妹子的SQL改了一下：

select distinct * from prvt_pub_stmt_vnwhere issue_time >= &#39;2020-08-01&#39;and issue_time <= &#39;2020-08-01&#39;and prs_dmtd_cde in (&#39;p&#39;,&#39;n&#39;,&#39;P&#39;,&#39;N&#39;);复制代码

查出來的結果竟然是一樣的。這就。 。 。

在妹子麵前當然不能說不行啊，於是讓妹子先回去再看看。

我這邊飛快的上網查了查，發現竟然是MySQL 的編碼格式和排序規則的問題。

知其所以然

我們MySQL資料庫基本上用的都是 utf8 的編碼格式，而 utf8 編碼格式還存在各種排序規則。常用的如下：

utf8_bin：將字串中的每一個字元以十六進位方式儲存數據，區分大小寫。

utf8_general_ci：不區分大小寫，ci為case insensitive的縮寫，即大小寫不敏感。

再查一下預設的字元集設定：

剛好 utf8 編碼格式的預設排序規則就是：utf8_general_ci－也就是不區分大小寫。

解決方案

問題原因找到了，那就對症下藥好了。

解決方法自然就是直接修改欄位的 collat​​e 屬性為 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 >= &#39;2020-08-01&#39;and issue_time <= &#39;2020-08-01&#39;and binary prs_dmtd_cde in (&#39;p&#39;,&#39;n&#39;);复制代码

Mysql 預設查詢是不分大小寫的，可以在 SQL 語句中加入 binary 來區分大小寫。

binary 不是函數，是類型轉換運算符，它用來強制它後面的字串為一個二進位字串，可以理解為在字串比較的時候區分大小寫。

最後

問題解決了，當然是去告訴妹子這個問題多麼多麼深奧，我又是如何剖析原理最終解決的了。

看著妹子投來的崇拜目光，當然是很開心了。

最最重要的還是要記住這個問題，以後在遇到字段大小寫敏感的業務，建表的時候要注意字符集和排序規則的選擇，以避免今天這種事情的發生。

想了解更多程式設計學習，請關注php培訓欄位！

#

以上是MySQL的where查詢的重新認識的詳細內容。更多資訊請關注PHP中文網其他相關文章！