在业务要求高的数据库中，对于单次删除更新操作，删除更新后加limit1绝对是个好习惯。例如，在删除执行中，第一项命中删除的行。如果SQL中有limit1，则此时返回，否则返回前进行??全表扫描。效率不言而喻。那么，我们需要养成每天执行delete时加limit的习惯吗？这是一个好习惯吗？在日常的SQL编写中，你有没有在写delete语句的时候用过下面的SQL？从t中删除，其中sex=1limit100；您以前可能没有使用过它。一般场景下，对于delete后是否加limit这个问题，我们是很陌生的，不知道有什么区别。今天就带大家一探究竟，记得标记哦！写在前面，如果要清空表数据，建议直接使用truncate。truncate的效率比delete高很多。应该是因为truncate不走事务，不锁表，不会产生大量的日志写入日志文件；truncatetabletable_name后立即释放磁盘空间并重置auto_increment的值。delete不会释放磁盘空间，但随后的insert会覆盖之前删除的数据。详情请跳转另一篇博文《delete、truncate、drop 的区别有哪些，该如何选择》以下只讨论删除场景。首先，delete后支持limit关键字，但只支持一个参数，即[limitrow_count]，用于在控制命令返回给之前通知服务器的最大删除行数客户。删除限制的语法如下。值得注意的是orderby必须和limit一起使用，否则会被优化。delete\[low\_priority\]\[quick\]\[ignore\]fromtbl\_name\[where...\]\[orderby...\]\[limitrow\_count\]pluslimit优点：以如下SQL为例：deletefromtwheresex=1;1.降低写错SQL的成本，即使删错一条，比如limit500，也会丢失500条数据，这不是致命的，数据也可以通过binlog快速恢复。2、为了避免长事务，MySQL会在执行delete时对所有涉及到的行加上写锁和Gap锁（间隙锁），所有与DML语句执行相关的行都会被加锁。如果删除数量大，将直接影响相关业务。使用。3、删除大量数据时，不加限制很容易把CPU占满，导致删除速度变慢。关于上面的第二点，前提是在sex上加了一个指标。大家都知道锁定是基于索引的。如果sex字段没有索引，就会扫描到主键索引。即使只有一条sex=1的记录，也会锁表。关于deletelimit的使用，mysql大佬丁奇有个疑问：如果要删除一个表的前10000行数据，有3种方法：第一种，直接执行deletefromT限制10000；二是在一个连接中执行deletefromTlimit50020次；三是同时对20个连接执行deletefromTlimit500。你先想一想，再看看几位老手的回答：TonyDu：方案一，如果事务比较长，会长时间占用锁，导致其他客户端等待一个资源很久。方案二，串行化执行，将一个比较长的事务分成多个比较短的事务，每个事务占用锁的时间比较短，其他客户端等待相应资源的时间也比较短。这样的操作也意味着资源是分片使用的（每次执行使用不同的分片资源），可以提高并发性。方案三，人们为自己制造锁竞争，增加并发量。方案2相对较好，需要结合实际业务场景。Roshan：抛开并发数据表访问不谈，如果我们简单比较这三种方案。第一种方案，一次占用的锁时间长，可能导致其他客户端一直在等待资源。第二种方案分为多个锁占用，串行执行，其他客户端可以在不占用锁的间隙工作。类似于现在多任务操作系统的时间片调度。每个人都是分片使用资源，不直接影响使用。第三种方案是自己创建锁竞争来强化并发。至于选择哪种方案，要结合实际场景，综合考虑各种因素，比如表的大小、并发量、业务对这张表的依赖程度等。~嗡嗡声：1.直接删除10000可能会使交易的执行时间过长。2、效率低。每个周期都是一个新的短交易，不会锁定同一条记录。重复执行DELETE只会影响行为0。3.虽然效率高，但是容易锁住同一条记录，死锁的可能性比较大。如何删除表的前10,000行。很多朋友都选择了第二种方法，即：在一个连接周期内执行20次deletefromTlimit500。确实是这样，第二种方式相对来说更好一些。第一种方式（即：直接执行deletefromTlimit10000），单条语句耗时较长，加锁时间也比较长；而且大事务也会造成主从延迟。第三种方式（即：同时在20个连接中执行deletefromTlimit500），会人为造成锁冲突。这个例子对我们实践的指导意义是在删除数据的时候尽量增加limit。这样既可以控制删除数据的数量，使操作更加安全，又可以减少加锁的范围。因此，先删除后添加限制是一个值得养成的好习惯。那么，这篇文章就带你了解这些。如果您有相关的问题和好的想法，请在下方留言，方便您与小伙伴一起讨论。作者：_陈哈哈https://blog.csdn.net/qq_3939...
