你好，我是yes。

創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),云安企業(yè)網(wǎng)站建設(shè),云安品牌網(wǎng)站建設(shè),網(wǎng)站定制,云安網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷,網(wǎng)絡(luò)優(yōu)化,云安網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

我的 VIP 用戶又拋給我一個(gè) SQL 問題，我很激動(dòng)，因?yàn)樗夭挠謥砹耍?/p>

我一看，這個(gè)表沒什么花頭，不就是沒設(shè)置主鍵嗎，MySQL 會(huì)默認(rèn)生成一個(gè)主鍵，這跟 delete 不掉數(shù)據(jù)好像也沒啥關(guān)系。

然后他說：

delete from a where device_id = '1239898' and task_id = '00111133445566';

這樣刪除不掉。

但是用 navicat 界面選擇某一行點(diǎn)擊刪除可以刪掉，然后他發(fā)現(xiàn)這樣操作刪除的 SQL 在尾部加上了  ESCAPE '#';

delete from a where device_id = '1239898' and task_id like '00111133445566' ESCAPE '#';

不知道為啥在界面手動(dòng)刪除用的是 like ，但是先不管，反正根據(jù)這個(gè)現(xiàn)象他暫時(shí)得出了一個(gè)結(jié)論，這個(gè)表的數(shù)據(jù)加ESCAPE '#'; 才刪的掉。

我一聽更興奮了，這是什么奇怪的操作！

ESCAPE 是什么？

這個(gè) ESCAPE 是一個(gè)關(guān)鍵字，它的作用其實(shí)很簡(jiǎn)單：替代轉(zhuǎn)義的字符。

我們都知道跟 like 有關(guān)的 % 的作用，它能匹配任意多個(gè)字符。

比如 select * from a where name like '陳%';

這條語句就能把 a 表中姓陳的人都查找出來。

那現(xiàn)在有個(gè)人他叫“陳%2”，你只想找“陳%”開頭的 name。

此時(shí)你就不能用 like '陳%'，你需要用 like '陳 \ %%'：

這里的 \ 就是轉(zhuǎn)義符，它的作用是把緊跟后面的這個(gè)字符轉(zhuǎn)義成正常的字符，不再具有它之前的含義（像 %之前的含義就是匹配任意多個(gè)字符）。

而 ESCAPE 的作用就是聲明另一個(gè)字符來替換 \ 。

比如 select * from a where name like '陳#%%' ESCAPE "#";

這樣一聲明，# 就達(dá)到了 \ 的效果。

回到問題上來

現(xiàn)在我們已經(jīng)明白了 ESCAPE 的作用，那么它跟開頭的問題有什么關(guān)系嗎？

我不知道，但是我很興奮，我開始瘋狂查閱資料。

google 無。

chatgpt 無。

newbing無。

MySQL官網(wǎng)無。

然后開始懷疑了：

好像看起來沒什么特別的。

然后我又過了一遍跟他的聊天記錄。

我直呼好家伙??！

他寫的 SQL 是：

實(shí)際的數(shù)據(jù)是 ：

所以他把兩個(gè)條件寫錯(cuò)了，task_id 是 1239898，device_id 才是那個(gè)一長(zhǎng)串！??！

我估計(jì)這位同學(xué)之所以沒看出來的原因是客戶端手動(dòng)刪除的操作能刪掉：

且產(chǎn)生了奇怪的  SQL，莫名加了  ESCAPE '#'，讓我們的這位同學(xué)一下子陷入了沉思。

實(shí)際上手動(dòng)刪除的 SQL 這么奇怪就是因?yàn)楸頉]有主鍵，不然正常手動(dòng)的刪除 SQL 上 where 條件肯定是 id =xxx。

至于為什么加了 ESCAPE '#' 其實(shí)我也沒懂，我查了查也也沒查到。

如果知道的大佬歡迎留言指導(dǎo)下！

最后

所以，這并不是一個(gè)奇怪的 SQL 問題，只是一個(gè)小疏忽。

其實(shí)這種問題在編程上很常見，比如在 postman 調(diào)試的時(shí)候，分頁數(shù)據(jù)寫反了，pageSize寫了1，pageNumer 寫了 10 ，導(dǎo)致怎么查都沒數(shù)據(jù)，怎么 debug 都看蒙了。

因?yàn)槭韬霎a(chǎn)生了很多奇奇怪怪、五花八門的問題，然后花了很多時(shí)間去找答案，還找不到。

最終沉下心來總的再過一遍才會(huì)發(fā)現(xiàn)，或者只能求助于同事。

我知道有問題，但是深陷其中當(dāng)局者迷，花了兩個(gè)小時(shí)還沒解決，同事 10s 就能看出來。

所以遇到事情不要不好意思，要主動(dòng)求助同事，不然那兩個(gè)小時(shí)是真的痛苦！

本文標(biāo)題：我們一起聊聊奇怪的SQL問題+1
本文地址：http://uogjgqi.cn/article/cdeepgo.html