为何MySQL中两个使用WHERE IN的DELETE查询执行结果不同

逐行拆解第一条SQL的执行逻辑 #

你第一条执行结果不符合预期的SQL，实际运行的匹配规则可以拆成两步看：

1. 先执行内层子查询：SELECT user_id FROM A WHERE date(created_date)=date("2021-04-20") AND user_id="Amy"
   这个查询返回的结果只有一个值：'Amy'
   你原本想通过内层的时间条件锁定目标数据，但实际拿出来作为IN匹配值的只有user_id字段，相当于时间筛选的作用止步于内层查询，外层完全感知不到这个限制。
2. 外层DELETE的WHERE条件实际被简化为：user_id IN ('Amy') AND user_id = 'Amy'
   这个条件的含义就是匹配所有user_id等于Amy的记录，所以最终把Amy名下的3条记录全部删掉，自然不符合预期。

逐行拆解第二条SQL的执行逻辑 #

你第二条执行成功的SQL，同样拆成两步看：

1. 先执行内层子查询：SELECT created_date FROM A WHERE date(created_date)=date("2021-04-20") AND user_id="Amy"
   这个查询返回的结果只有一个值：'2021-04-20 17:00:00'
2. 外层DELETE的WHERE条件实际被简化为：created_date IN ('2021-04-20 17:00:00') AND user_id = 'Amy'
   这个条件刚好匹配id=19、属于Amy、创建时间为2021-04-20的那一条记录，所以结果符合预期。

这里对IN子查询的理解存在一个常见的偏差：

• 你误以为内层子查询写的所有WHERE筛选条件，都会自动透传到外层的删除逻辑上。但实际上IN关键字的作用，是把内层查询返回的结果当成一个常量值集合，用来匹配WHERE指定的那一个外层列的值。
• 内层查询里写的其他筛选条件，仅仅是用来约束“哪些值会被放进这个待匹配的集合里”，不会变成外层的筛选规则。
• 举个直白的对照：
  • 内层查user_id，哪怕你在内层加再多时间、其他字段的限制，只要最终返回的user_id值是'Amy'，外层匹配的时候就只会认“记录的user_id等于Amy”这个规则，完全不会记得内层曾经做过时间筛选。
  • 内层查created_date，哪怕你在内层加再多user_id的限制，只要最终返回的created_date值是2021-04-20对应的时间，外层就只会匹配这个时间值的记录，再搭配你外层写的user_id='Amy'，刚好凑成完整的筛选条件。

你本来要实现的“仅当存在对应数据时才删除Amy在2021-04-20的记录”，完全不需要写嵌套子查询绕弯路，直接把所有筛选条件平铺在DELETE的WHERE子句里即可：

DELETE FROM A
WHERE user_id = 'Amy'
  AND DATE(created_date) = '2021-04-20';

这种写法天然满足你的需求：如果没有匹配到对应记录，语句会正常执行，只是返回受影响行数为0，不会产生误删；如果存在匹配的记录，就精准删除对应行。
之前你写嵌套子查询的写法，本质是绕开MySQL早期版本中“DELETE操作不能直接在同表的子查询中引用原表”的限制，属于完全没必要的冗余写法，既容易写混筛选条件，执行效率也更低。

内容的提问来源于stack exchange，提问作者lecor