我一看，这个表没什么花头，不就是没设置主键吗，MySQL 会默认生成一个主键，这跟 delete 不掉数据好像也没啥关系。

然后他说：

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

这样删除不掉。

但是用 navicat 界面选择某一行点击删除可以删掉，然后他发现这样操作删除的 SQL 在尾部加上了  ESCAPE '#';

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

不知道为啥在界面手动删除用的是 like ，但是先不管，反正根据这个现象他暂时得出了一个结论，这个表的数据加ESCAPE '#'; 才删的掉。

我一听更兴奋了，这是什么奇怪的操作！

这个 ESCAPE 是一个关键字，它的作用其实很简单：替代转义的字符。

我们都知道跟 like 有关的 % 的作用，它能匹配任意多个字符。

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

这条语句就能把 a 表中姓陈的人都查找出来。

那现在有个人他叫“陈%2”，你只想找“陈%”开头的 name。

此时你就不能用 like '陈%'，你需要用 like '陈 \ %%'：

这里的 \ 就是转义符，它的作用是把紧跟后面的这个字符转义成正常的字符，不再具有它之前的含义（像 %之前的含义就是匹配任意多个字符）。

而 ESCAPE 的作用就是声明另一个字符来替换 \ 。

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

这样一声明，# 就达到了 \ 的效果。

现在我们已经明白了 ESCAPE 的作用，那么它跟开头的问题有什么关系吗？

我不知道，但是我很兴奋，我开始疯狂查阅资料。

google 无。

chatgpt 无。

newbing无。

MySQL官网无。

然后开始怀疑了：

好像看起来没什么特别的。

然后我又过了一遍跟他的聊天记录。

我直呼好家伙！！

他写的 SQL 是：

实际的数据是 ：

所以他把两个条件写错了，task_id 是 1239898，device_id 才是那个一长串！！！

我估计这位同学之所以没看出来的原因是客户端手动删除的操作能删掉：

且产生了奇怪的  SQL，莫名加了  ESCAPE '#'，让我们的这位同学一下子陷入了沉思。

实际上手动删除的 SQL 这么奇怪就是因为表没有主键，不然正常手动的删除 SQL 上 where 条件肯定是 id =xxx。

至于为什么加了 ESCAPE '#' 其实我也没懂，我查了查也没查到。

如果知道的大佬欢迎留言指导下！

所以，这并不是一个奇怪的 SQL 问题，只是一个小疏忽。

其实这种问题在编程上很常见，比如在 postman 调试的时候，分页数据写反了，pageSize写了1，pageNumer 写了 10 ，导致怎么查都没数据，怎么 debug 都看蒙了。

因为疏忽产生了很多奇奇怪怪、五花八门的问题，然后花了很多时间去找答案，还找不到。

最终沉下心来总的再过一遍才会发现，或者只能求助于同事。

我知道有问题，但是深陷其中当局者迷，花了两个小时还没解决，同事 10s 就能看出来。

所以遇到事情不要不好意思，要主动求助同事，不然那两个小时是真的痛苦！