新入职的女同事问我，执行delete时，需要加limit吗？
Java高效学习
共 2679字，需浏览 6分钟
·
2020-10-29 22:56
来源：https://blog.csdn.net/qq_39390545/article/details/107519747
比如，在删除执行中，第一条就命中了删除行，如果SQL中有limit 1；这时就return了，否则还会执行完全表扫描才return。效率不言而喻。
那么，在日常执行delete时，我们是否需要养成加 limit 的习惯呢？是不是一个好习惯呢？
在日常的SQL编写中，你写delete语句时是否用到过以下SQL？
delete from t where sex = 1 limit 100;
写在前面，如果是清空表数据建议直接用truncate，效率上truncate远高于delete，应为truncate不走事务，不会锁表，也不会生产大量日志写入日志文件；truncate table table_name 后立刻释放磁盘空间，并重置auto_increment的值。delete删除不释放磁盘空间，但后续insert会覆盖在之前删除的数据上。
delete [low_priority] [quick] [ignore] from tbl_name[where ...][order by ...][limit row_count]
加limit的的优点
delete from t where sex = 1;
对于delete limit 的使用，MySQL大佬丁奇有一道题：
如果你要删除一个表里面的前 10000 行数据，有以下三种方法可以做到：
第一种，直接执行 delete from T limit 10000;
第二种，在一个连接中循环执行 20 次 delete from T limit 500;
第三种，在 20 个连接中同时执行 delete from T limit 500。
方案一，事务相对较长，则占用锁的时间较长，会导致其他客户端等待资源时间较长。
方案二，串行化执行，将相对长的事务分成多次相对短的事务，则每次事务占用锁的时间相对较短，其他客户端在等待相应资源的时间也较短。这样的操作，同时也意味着将资源分片使用（每次执行使用不同片段的资源），可以提高并发性。
方案三，人为自己制造锁竞争，加剧并发量。
方案二相对比较好，具体还要结合实际业务场景。
--------------------------------------------
不考虑数据表的访问并发量，单纯从这个三个方案来对比的话。
第一个方案，一次占用的锁时间较长，可能会导致其他客户端一直在等待资源。
第二个方案，分成多次占用锁，串行执行，不占有锁的间隙其他客户端可以工作，类似于现在多任务操作系统的时间分片调度，大家分片使用资源，不直接影响使用。
第三个方案，自己制造了锁竞争，加剧并发。
-------------------------------------------
～嗡嗡：
直接delete 10000可能使得执行事务时间过长
效率慢点每次循环都是新的短事务，并且不会锁同一条记录，重复执行DELETE知道影响行为0即可
效率虽高，但容易锁住同一条记录，发生死锁的可能性比较高
长按关注，学习更多
推荐阅读
评论