Mysql中的Delete *** 作

delete *** 作一般用于删除数据表中的某一行，常见的语法如下：

如果我们不在这条语句后面添加where筛选条件，则视为删除数据表的所有行，这里我们只对这种简单的使用方式加以回顾，并不举例说明。

如果在特定的场景中，需要使用sql语句删除重复的行，那我们应该如何 *** 作呢。这里给出一个具体的例子，例如 Leetcode 196 删除重复的邮箱 中需要我们使用delete命令删除重复的电子邮箱。

首先，需要使用自连接语句筛选出重复的电子邮箱id。

此时，我们将重复的电子邮箱查询出来。

然后，就需要使用delete语句，此时涉及到的是一个多表删除的语句，应该写成如下格式：

我们发现在delete和from之间加入了一个p1，这代表只删除p1表中满足筛选条件的行，而p1代表person，最终就完成了对person表的delete *** 作。

首先，我们仍然需要筛选出重复的电子邮箱的id。

然后，在person删除对应上述的id。

有一个计费表jifei，其中包含的字段有：phone（8位电话号码)、month（月份）、expense（月消费，费用为0表明该月没有产生费用），请你删除jifei表中所有10月份出现的两条相同记录的其中一条记录。

此题目中需要多个字段重复即删除，所以第一步仍然需要筛选出需要删除的行。

然后使用delete删除重复的行。

​ 上述两个步骤实际上删除的所有重复出现的行，但是题目需要删除10月份重复出现两次的记录，所以还需要内联结一个对月份记录的字段。

你写了一条正常的update 或者 delete 语句时，语句本身是没问题的，但是却执行不了。原因是是MySQL Workbench的安全设置。当要执行的SQL语句是进行批量更新或者删除的时候就会提示这个错误。

打开Workbench的菜单Edit->Preferences xxx->切换到SQL Editor

把Forbid UPDATE and DELETE statements without a WHERE clause (safe updates)的勾去掉击[OK]按钮重新启动就OK了。

或者在每句语句前，加上‘SET SQL_SAFE_UPDATES=0’

问题就解决了。

（ps：以后我会分享我所遇到的问题，这里持续更新！）

实际这里是是一个delete in语句。

大概就是这样一个语句，处于preparing 状态，问delete为什么会处于这个状态？

对于preparing状态一般归结为优化阶段，并还没有进入实际的语句执行阶段。但是这里有所不同。并且我们知道一般delete执行慢一般状态会处于，

但是这里是preparing状态。那么为什么会处于这种状态呢？简单分析一下。

我们知道5.7的delete in实际上还是用的DEPENDENT SUBQUERY。这个类似exists的 *** 作，都会用外层查询驱动内层。稍微跟了一下5.7的delete in（不做详细研究），发现所有的query block并没有完全完成优化，实际上这种子查询会在调用Item_subselect::exec的时候通过

进行判断，如果unit->is_optimized()判断为false，则会调入unit->optimize(thd)，对subquery的query block进行优化，而优化结束后查询的状态会被设置为preparing。也就出现了这种现象，如下：

这种现象当前看起来是5.7（5.7以下没有测试）中DML语句带in/not in常见的，也可以归结为状态转换稍微考虑欠妥，可能开发大佬也没意识到这个状态已经变为DBA诊断问题的一个主要手段。

而到了8.0状态已经更加精细，有了一些细微的变化，而且8.0.21后支持DML 中的in使用semi join(not in还不行，但是状态是executing）优化。所以我们简单的将其归结为正在执行类似sending data状态即可。需要优化的是将这种delete改写为联合delete形式。

---