記一次字符串末尾空白丟失的排查 → MySQL 是會玩的!

開心一刻

  今天答應準時回家和老婆一起喫晚飯,但臨時有事加了會班,回家晚了點

  回到家,本以爲老婆會很生氣,但老婆卻立即從廚房端出了熱着的飯菜

  老婆:還沒喫飯吧,去洗下,來喫飯吧

  我洗好,坐下喫飯,內心感動十分;老婆坐旁邊深情的看着我

  老婆:你知道誰最愛你嗎

  我毫不猶豫道:你

  老婆:誰最關心你?

  我:你

  老婆:我是誰呀?

  我:我老婆

  老婆:那你以後是不是得對我好點?

  這時電話響了,一看好哥們打過來的,我接了並開了免提

  哥們:樓下洗浴八折,幹啥呢?

  我:那個......,在陪我前妻喫口飯

問題背景

  一天,小夥伴找到我,他說他碰到一個很奇怪的問題

  他說:明明表名的入參是 test  ,爲什麼展示到界面的記錄包括 test 這條記錄?

  他補充道:會不會是 MyBatis-Plus 做了什麼騷操作,把 test  末尾的空格給拿掉了

  我:你直接把 SQL 語句到 MySQL 執行下試試

  結果如下:

  這看起來不夠直觀,我移動下光標

  然後我和小夥伴面面相覷

環境準備

   MySQL5 、 MySQL8 各準備一個

  我們來看下默認情況下,末尾空白的判斷情況

   MySQL 5.7.36 如下

  1 表示 TRUE ,也就是相等

   MySQL 8.0.27 如下

  0 表示 FALSE ,表示不相等

  這是什麼原因,我們繼續往下看

字符集與字符序

  比較肯定就需要比較規則, SQL 的比較規則就離不開字符序,字符序又與字符集相關,所以我們一個一個來捋

  字符集

  關於字符集,不是隻言片語可以說清楚的,但是大家也不用擔心,網上相關資料已經非常多,大家擦亮慧眼去查閱即可

  簡單點來說:字符集定義了字符和字符的編碼

  有人又問了:字符、字符的編碼又是什麼?

  爲了方便大家理解,舉個簡單栗子

    有四個字符:A、B、C、D,這四個字符的編碼分別是 A = 0, B = 1, C = 2, D = 3

    這裏的字符(A、B、C、D) + 編碼(0、1、2、3)就構成了字符集(character set)

   MySQL 支持的字符集有很多,可以通過 SHOW CHARACTER SET; 查看

   Charset :字符集名

   Description :描述

   Default collation :默認字符序

   Maxlen :每個字符最多字節數

  字符序

  定義了字符的比較規則;字符間的比較按何種規則進行

  一個字符集對應多個字符序,通過 SHOW COLLATION; 可以查看全部的字符序;也可以帶條件查具體某個字符集的字符序

   Default 等於 Yes 表示是默認字符序

  每個字符集都有默認的字符序

  server的字符集與字符序

  當我們創建數據庫時,沒有指定字符集、字符序,那麼server字符集、server字符序就會作爲該數據庫的字符集、字符序

  database的字符集與字符序

  指定數據庫級別的字符集、字符序

  同一個MySQL服務下的數據庫,可以分別指定不同的字符集、字符序

  創建、修改數據庫的時候,可以通過 CHARACTER SET 、  COLLATE  指定數據庫的字符集、字符序

  可以通過

  查看數據庫的字符集和字符序

  table的字符集與字符序

  創建、修改表的時候,可以通過 CHARACTER SET 、 COLLATE 指定表的字符集、字符序

  可以通過

  查看錶的字符序

  column的字符集與字符序

  類型爲 CHAR 、 VARCHAR 、 TEXT 的列,可以指定字符集、字符序

  可以通過

  查看字段的字符集和字符序

  多個維度指定字符集、字符序的話,粒度越細的優先級越高( column > table > database > server )

  如果細粒度未指定字符集、字符序,那麼會繼承上一級的字符集,字符序則是上一級字符集的默認字符序

  通常情況下我們一般不會指定 table 、 column 粒度的字符集、字符序

  也就是說,通常情況下 column 的字符集會與 database 的字符集一致,而 column 的字符序則是 database 字符集的默認字符序

空白丟失

  上面講了那麼多,跟空白丟失有什麼關係?

  大家先莫急,繼續往下看

   MySQL5.7 The CHAR and VARCHAR Types中有這麼一段

  翻譯過來就是:

    1、類型是 CHAR 、 VARCHAR 、 TEXT 列的值,會根據列的字符序來比較和排序

    2、所有 MySQL 排序規則的類型都是 PAD SPACE 。這就意味着, CHAR 、 VARCHAR 、 TEXT 類型的值進行比較時,不用考慮任何末尾空格,LIKE 除外

    3、不受 SQL mode 影響,也就是說不管是嚴格模式,還是非嚴格模式,都不影響 2 所說的規則

  劃重點,記筆記:在 MySQL5.7 及以下( <=5.7 )版本中,排序規則都是 PAD SPACE ,末尾的空格會忽略不考慮

  那如何讓末尾空格參與比較了,有三種處理方式

  1、 BINARY ,類似 SELECT 'test' = BINARY 'test '; 

  2、 LIKE ,類似 SELECT 'test' LIKE 'test '; 

  3、 LENGTH 函數,類似

   MySQL8 做了調整,The CHAR and VARCHAR Types 有如下說明

  翻譯過來就是:

    1、類型是 CHAR 、 VARCHAR 、 TEXT 列的值,會根據列的字符序來比較和排序

    2、 MySQL 字符序的 pad 參數的可選值,除了 PAD SPACE ,還增加了 NO PAD 

    3、對於非二進制字符串( CHAR 、 VARCHAR 、 TEXT ),字符序 pad 參數決定如何去處理字符串末尾的空格

       NO PAD 不會忽略末尾空格,會將其當做其他字符一樣對待

       PAD SPACE 會忽略末尾空格, LIKE 除外

       SQL mode 不參與字符串末尾空格的處理

   MySQL8 server 維度的字符集是 utf8mb4 ,對應的默認字符序是: utf8mb4_0900_ai_ci 

   Pad_attribute 的值是 NO PAD ,也就是不會忽略字符串末尾的空格

  所以在 MySQL8 中, SELECT 'test' = 'test '; 默認情況下得到的結果是 0

總結

  1、非二進制字符串( CHAR 、 VARCHAR 、 TEXT )比較時,末尾空格的處理跟列的字符序有直接關係

  2、 MySQL5.7 及之前的版本,排序規則的類型都是 PAD SPACE ,會忽略字符串末尾的空格, LIKE 除外

  3、 MySQL8 開始,字符序增加了一個參數 Pad_attribute ,該參數的值不同,對字符串末尾空格的處理方式不同

     NO PAD :字符串末尾的空格會和其他字符一樣,不會被忽略

     PAD SPACE :字符串末尾的空格會被忽略, LIKE 除外

  4、如上針對的都是非二進制字符串的排序和比較,而不是儲存

參考

  The CHAR and VARCHAR Types

  The CHAR and VARCHAR Types

  再見亂碼:5分鐘讀懂MySQL字符集設置

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章