删除数据库记录前是否有必要先查看记录是否存在

为什么要删除，标记一下不就好了…

数据订正，先备份下，再直接删

删库跑路!

觉得没必要，如果删除的数据不存在，会返回 0

加入 limit 1

用户初始化一个工单, 如果这个工单没有被指派, 那么用户可以取消(删除), 如果被指派了, 不能取消.


你如果不检测状态, 怎么删除?

@lihongjie0209 #6 一般设计里面不会取消也不会删除的，改一下状态就可以了。

一般不做 delete 操作，而是用字段代表是否被删除

@wd 哪怕是改状态, 你也不应该把不可以删除的数据标记为删除. 你的程序要做业务校验的

@lihongjie0209 @wd @Caballarii @hubqin @gavindexu @zhuangzhuang1988
其实是这样，先 delete，然后重新 insert 的一个场景，这套操作在修改的接口里面，我看先查询一遍再删除，觉得没必要，因为没相应记录删除也不会报错(代码不是我写的)

一般是有个 status 字段标识记录是否有效

各家公司生产上但凡是专业 dba 设计的数据库架构都不会有删除操作，一般删数据这种多见于开发神魔乱舞

@lihongjie0209 #9 数据一般都是不可以删除的，因为数据之间一旦加了约束之后，删除是会破坏约束的，而且用户老板的各种不确定性，保留数据可以用来查历史，甚至必要的时候恢复这个数据。和写程序里面的不能写死累死。你说的程序需要做校验我理解是说需要代码识别这样的数据做不同处理吗？那这个自然是需要做的。

@alienx717 #10 就你说的这个，如果确实没有什么特殊的要求，那直接删就可以，我觉得不用先查一下.

做硬删除反而「不是正道」，这个世道 ♂

从来没见过真删除，都是软删

在高并发场景下可出现两个进程同时查询同一条数据是否存在，两个进程可能同时查出来这一条数据存在，然后同时执行删除，一个成功删除了，另一个没有成功删除，只是一般也不会报错就是了。

所以……先查询后删除的原因是什么呢？如果是从性能上来说，先查询后删除性能比直接删除多一步，直接删除如果没有记录也不会执行写操作（数据库一般都会 对各种已知情况做足优化的）；从逻辑上来说，删除操作时幂等的，即不管删除前有没有数据，执行删除后的结果都是一致的。

所以我的答案是：直接删就可以了。

逻辑删除不就是查出来再“删”