delete后加 limit是个好习惯么？
★★★建议星标我们★★★
文章插图
文章插图
2020年Java原创面试题库连载中
【000期】Java最全面试题库思维导图
【020期】JavaSE系列面试题汇总（共18篇）
【028期】JavaWeb系列面试题汇总（共10篇）
【042期】JavaEE系列面试题汇总（共13篇）
【049期】数据库系列面试题汇总（共6篇）
【053期】中间件系列面试题汇总（共3篇）
【065期】数据结构与算法面试题汇总（共11篇）
【076期】分布式面试题汇总（共10篇）
【077期】综合面试题系列（一）
【078期】综合面试题系列（二）
【079期】综合面试题系列（三）
【080期】综合面试题系列（四）
【081期】综合面试题系列（五）
【082期】综合面试题系列（六）
【083期】综合面试题系列（七）
【084期】综合面试题系列（八）
【085期】综合面试题系列（九）
【delete后加 limit是个好习惯么？】【086期】综合面试题系列（十）
【087期】综合面试题系列（十一）
【088期】综合面试题系列（十二）
【089期】综合面试题系列（十三）
更多内容 ， 点击上面蓝字查看
文章插图
作者：_陈哈哈
在业务场景要求高的数据库中 ， 对于单条删除和更新操作 ， 在 delete 和 update 后面加 limit 1 绝对是个好习惯 。 比如 ， 在删除执行中 ， 第一条就命中了删除行 ， 如果 SQL 中有 limit 1；这时就 return 了 ， 否则还会执行完全表扫描才 return 。 效率不言而喻 。
那么 ， 在日常执行 delete 时 ， 我们是否需要养成加 limit 的习惯呢？是不是一个好习惯呢？
在日常的 SQL 编写中 ， 你写 delete 语句时是否用到过以下 SQL？
delete from t where sex = 1 limit 100; 你或许没有用过 ， 在一般场景下 ， 我们对 delete 后是否需要加 limit 的问题很陌生 ， 也不知有多大区别 ， 今天带你来了解一下 ， 记得 mark！
写在前面 ， 如果是清空表数据建议直接用 truncate ， 效率上 truncate 远高于 delete ， 应为 truncate 不走事务 ， 不会锁表 ， 也不会生产大量日志写入日志文件；truncate table table_name 后立刻释放磁盘空间 ， 并重置 auto_increment 的值 。 delete 删除不释放磁盘空间 ， 但后续 insert 会覆盖在之前删除的数据上 。 详细了解请跳转另一篇博文《delete、truncate、drop 的区别有哪些 ， 该如何选择》
下面只讨论 delete 场景 ， 首先 ， delete 后面是支持 limit 关键字的 ， 但仅支持单个参数 ， 也就是 [limit row_count] ， 用于告知服务器在控制命令被返回到客户端前被删除的行的最大值 。
delete limit 语法如下 ， 值得注意的是 ， order by 必须要和 limit 联用 ， 否则就会被优化掉 。
delete \[low\_priority\] \[quick\] \[ignore\] from tbl\_name\[where ...\]\[order by ...\]\[limit row\_count\]加 limit 的的优点：以下面的这条 SQL 为例：
delete from t where sex = 1;
- 1. 降低写错 SQL 的代价 ， 就算删错了 ， 比如 limit 500, 那也就丢了 500 条数据 ， 并不致命 ， 通过 binlog 也可以很快恢复数据 。
- 2. 避免了长事务 ， delete 执行时 MySQL 会将所有涉及的行加写锁和 Gap 锁（间隙锁） ， 所有 DML 语句执行相关行会被锁住 ， 如果删除数量大 ， 会直接影响相关业务无法使用 。