SQL中delete后加 Limit是个好习惯么？

导读：在业务场景要求高的数据库中，对于单条删除和更新操作，在delete和update后面加limit 1绝对是个好习惯。比如，在删除执行中，第一条就命中了删除行，如果SQL中有limit 1；这时就return了，否则还会执行完全表扫描才return。效率不言而喻。

那么，在日常执行delete时，我们是否需要养成加 limit 的习惯呢？是不是一个好习惯呢？

在日常的SQL编写中，你写delete语句时是否用到过以下SQL？

你或许没有用过，在一般场景下，我们对 delete 后是否需要加 limit 的问题很陌生，也不知有多大区别，今天带你来了解一下，记得mark！

写在前面，如果是清空表数据建议直接用truncate，效率上truncate远高于delete，应为truncate不走事务，不会锁表，也不会生产大量日志写入日志文件；truncate table table_name 后立刻释放磁盘空间，并重置auto_increment的值。

delete删除不释放磁盘空间，但后续insert会覆盖在之前删除的数据上。

下面只讨论delete场景，首先，delete后面是支持limit关键字的，但仅支持单个参数，也就是[limit row_count]，用于告知服务器在控制命令被返回到客户端前被删除的行的最大值。

delete limit语法如下，值得注意的是，order by必须要和limit联用，否则就会被优化掉。

加Limit的优点

以下面的这条SQL为例：

• 1. 降低写错SQL的代价，就算删错了，比如limit 500,那也就丢了500条数据，并不致命，通过binlog也可以很快恢复数据。
• 2. 避免了长事务，delete执行时MySQL会将所有涉及的行加写锁和Gap锁（间隙锁），所有DML语句执行相关行会被锁住，如果删除数量大，会直接影响相关业务无法使用。
• 3. delete数据量大时，不加limit容易把cpu打满，导致越删越慢。

针对上述第二点，前提是sex上加了索引，大家都知道，加锁都是基于索引的，如果sex字段没索引，就会扫描到主键索引上，那么就算sex = 1 的只有一条记录，也会锁表。