对於单条记录的删除和更新来说，在delete或update后加limit是一个好习惯。其作用等同于select后加limit。若查询到记录直接返回，不会继续查询。
若是一般的场景中（删除多条），delete后加limit是否合适？
加锁是基于索引的，如果delete的where条件没有索引，就会扫描到主键索引上，就算只有一条记录，也会锁表。
在where条件上无索引的情况下，delete会锁整个表的记录，但是delete后加[limit row_count]，则是只锁[1-满足删除条数所在行]这些行。
此时stu_num字段无索引。
+----+--------------------------------+--------------------+---------+
| id | name | address | stu_num |
+----+--------------------------------+--------------------+---------+
| 3 | 衡水中学 | 河北省衡水市 | 1000 |
| 4 | 海淀中学 | 北京市海淀区 | 2000 |
| 5 | 海南中学 | 海南省 | 2000 |
| 6 | 天津大学附属第一中学 | 天津市和平区 | 1000 |
| 7 | 北京大学附属第一中学 | 北京市海淀区 | 1500 |
| 8 | 宁夏中学 | 宁夏省 | 400 |
| 15 | 内蒙古中学 | 内蒙古省 | 400 |
| 19 | 陕西第一小学 | 陕西省 | 1400 |
| 22 | 陕西第二中学 | 陕西省 | 1400 |
| 23 | 陕西第三中学 | 陕西省 | 1400 |
+----+--------------------------------+--------------------+---------+
10 rows in set (0.00 sec)
A事务：此时满足条件的主键id最大为15。
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> delete from t_school where stu_num =400 limit 2;
Query OK, 1 row affected (0.00 sec)
B事务查询：即A事务对1-15行加锁，可以看到，加锁查询id=22时没有问题，但是加锁查询id=5时记录被锁了。
mysql> select * from t_school where id =22 for update;
+----+--------------------+-----------+---------+
| id | name | address | stu_num |
+----+--------------------+-----------+---------+
| 22 | 陕西第二中学 | 陕西省 | 1400 |
+----+--------------------+-----------+---------+
1 row in set (0.00 sec)
mysql> select * from t_school where id =5 for update;
mysql> 2013 - Lost connection to MySQL server during query
mysql>
当然不推荐delete后的条件没有索引的情况，极易造成死锁。
使用limit的语法
- delete后面是支持limit关键字的，但仅支持单个参数，也就是[limit row_count]。
当需要用到order by排序时，必须order by + limit联用，否则order by 就会被优化器优化掉，被认为无意义。
使用limit的好处：
- 降低写错sql的代价；
- 避免长事务，delete多行时会对选中的所有行加锁；
- delete数量大时，不加limit会导致高cpu；
疑问：
如果你要删除一个表里面的前 10000 行数据，有以下三种方法可以做到：
第一种，直接执行 delete from T limit 10000;
第二种，在一个连接中循环执行 20 次 delete from T limit 500;
第三种，在 20 个连接中同时执行 delete from T limit 500。
Tony Du：
方案一，事务相对较长，则占用锁的时间较长，会导致其他客户端等待资源时间较长。
方案二，串行化执行，将相对长的事务分成多次相对短的事务，则每次事务占用锁的时间相对较短，其他客户端在等待相应资源的时间也较短。这样的操作，同时也意味着将资源分片使用（每次执行使用不同片段的资源），可以提高并发性。
方案三，人为自己制造锁竞争，加剧并发量。
方案二相对比较好，具体还要结合实际业务场景。
肉山：
不考虑数据表的访问并发量，单纯从这个三个方案来对比的话。
第一个方案，一次占用的锁时间较长，可能会导致其他客户端一直在等待资源。
第二个方案，分成多次占用锁，串行执行，不占有锁的间隙其他客户端可以工作，类似于现在多任务操作系统的时间分片调度，大家分片使用资源，不直接影响使用。
第三个方案，自己制造了锁竞争，加剧并发。
至于选哪一种方案要结合实际场景，综合考虑各个因素吧，比如表的大小，并发量，业务对此表的依赖程度等。
～嗡嗡：
- 直接delete 10000可能使得执行事务时间过长
- 效率慢点每次循环都是新的短事务，并且不会锁同一条记录，重复执行DELETE知道影响行为0即可
- 效率虽高，但容易锁住同一条记录，发生死锁的可能性比较高