點擊上方?好好學java?，選擇?星標?公眾號

重磅資訊、干貨，第一時間送達

今日推薦：又一程序員進了ICU：壓垮一個家庭，一張結算單就夠

個人原創100W+訪問量博客：點擊前往，查看更多

在業務場景要求高的數據庫中，對于單條刪除和更新操作，在 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 場景，首先，delete 后面是支持 limit 關鍵字的，但僅支持單個參數，也就是 [limit row_count]，用于告知服務器在控制命令被返回到客戶端前被刪除的行的最大值。

delete limit 語法如下：delete [low_priority] [quick] [ignore] from tbl_name [where ...] [order by ...] [limit row_count]

值得注意的是，order by 必須要和 limit 聯用，否則就會被優化掉。

加 limit 的的優點

delete from t where sex = 1;

以上面的這條 SQL 為例：

• 降低寫錯 SQL 的代價，就算刪錯了，比如 limit 500，那也就丟了 500 條數據，并不致命，通過 binlog 也可以很快恢復數據。

• 避免了長事務，delete 執行時 MySQL 會將所有涉及的行加寫鎖和 Gap 鎖（間隙鎖），所有 DML 語句執行相關行會被鎖住，如果刪除數量大，會直接影響相關業務無法使用。

• delete 數據量大時，不加 limit 容易把 CPU 打滿，導致越刪越慢。

針對上述第二點，前提是 sex 上加了索引。大家都知道，加鎖都是基于索引的，如果 sex 字段沒索引，就會掃描到主鍵索引上，那么就算 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 即可。

③效率雖高，但容易鎖住同一條記錄，發生死鎖的可能性比較高。

怎么刪除表的前 10000 行。比較多的朋友都選擇了第二種方式，即：在一個連接中循環執行 20 次 delete from T limit 500。

確實是這樣的，第二種方式是相對較好的。

第一種方式（即：直接執行 delete from T limit 10000）里面，單個語句占用時間長，鎖的時間也比較長；而且大事務還會導致主從延遲。

第三種方式（即：在 20 個連接中同時執行 delete from T limit 500），會人為造成鎖沖突。

這個例子對我們實踐的指導意義就是，在刪除數據的時候盡量加 limit。這樣不僅可以控制刪除數據的條數，讓操作更安全，還可以減小加鎖的范圍。

所以，在 delete 后加 limit 是個值得養成的好習慣。

作者：陳哈哈 簡介：MySQL 社區的非著名貢獻者，善于白嫖知識；陪伴 MySQL 五年，致力于高性能 SQL、事務鎖優化方面的研究；長路漫漫，希望通過自己的分享讓大家少踩一些坑。我是陳哈哈，一個愛笑的程序員。編輯：陶家龍 出處：轉載自公眾號 MySQL 江湖路（ID：mysql_chenhaha）

原創電子書

歷時整整一年總結的?Java 面試 + Java 后端技術學習指南，這是本人這幾年及校招的總結，各種高頻面試題已經全部進行總結，按照章節復習即可，已經拿到了大廠offer。

原創思維導圖

掃碼或者微信搜?程序員的技術圈子?回復?面試?領取原創電子書和思維導圖。

總結

以上是生活随笔為你收集整理的CTO说了，delete后不加limit，直接滚蛋！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。