有趣的mysql string和0比較傳回1的問題

title: 有趣的mysql string和0比較傳回1的問題 tags:

• mysql
• type
• String
• 0 categories: mysql date: 2017-06-25 18:18:56

6月19日出現了詭異的情況

開發環境所有的移動端使用者無法登陸。

移動端通過rmi來通路,為了移動端可以通路權限内的資料，是以增加了相關的權限控制 RMI鑒權

那麼對于登陸來說我們不會進行權限控制，此時要求必須傳遞的ClientInfo 為任意不存在的值。通常為了友善 我們傳遞的值為fake（赝品）

出現使用者無法登陸時通過調試發現了一條奇怪的資料

pk_id username cell_phone password is_admin id_role creator modifier modifiedtime creationtime id_own_org id_employee is_del is_guide_open id_wxb_user id_wxb_station openid

0 liuliu 18767564542 96e79218965eb72c92a549dd5a330112 0 919 10545055918000106903 2017-06-19 17:05:52 2017-06-19 17:05:42 10545055918000106902 0 0

那麼當執行sql如下

SELECT
        *
    FROM
        tb_user
    WHERE
        pk_id = 'fake'
複制代碼
           

可以查詢得出如上的資料（注 pk_id 為bigint(20) unsigned）

pk_id為使用uuid_short産生的，是以對應java中使用String作為類型存儲。

我們來檢視一下mysql關于type轉換的解釋

dev.mysql.com/doc/refman/…

我們執行如下sql

SELECT
         = '',
         = 'fake',
         = NULL,
         = ,
         = ,
         = '1',
         = '1.66',
         = '1.a',
         = 'a.1',
         = ' ',
         = ' 啊',
         = '',
        NULL = NULL,
        NULL <=> NULL,
        NULL <=> ,
        NULL = ,
         = cast('fake' AS UNSIGNED)
複制代碼
           

得到結果如下

我們發現如下問題0和任意不能直接parse數字(如果數字打頭可以parse)的比較均為true。換句話說我們認為所有不能parse為數字的值将會被parse為0

由于我們pk_id的類型為bigint unsigned 是以我們的參數江河數字進行比較，是以任何非數字打頭 這個解釋了我們在sql中為啥通過如上語句可以查詢到pk_id為0 的資料。因為‘fake被parse為0‘（可以粗略的這麼了解）

那麼問題來了，為何資料中插入的uuid_short會變成0呢？如果出現了這樣的問題那絕對是超出筆者所能了解的範圍了。

查詢binlog我們發現

插入的很明顯是有具體的數值的。

接着檢索到

很明顯确實是有人更新了主鍵（将主鍵更新成了 ’ ‘導緻落到資料庫中直接變成了0 ）===》具體的責任人（測試）不想去查了，各位更新時請注意。

問題解決。

最後複習一下

SELECT '0s' +  = 's','1s' +  = 's','0s' +  = 's1','s0' +  = 's00','s00' +  = 's00'
複制代碼
           

不在sql中執行 可以給出結果麼？