點擊上方「碼農突圍」，馬上關注
這裡是碼農充電第一站，回復「666」，獲取一份專屬大禮包
真愛，請設置「星標」或點個「在看」
作者：_陳哈哈
https://blog.csdn.net/qq_39390545/article/details/107519747
在業務場景要求高的資料庫中，對於單條刪除和更新操作，在 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\]
以下面的這條 SQL 為例：
delete from t where sex = 1;
1. 降低寫錯 SQL 的代價，就算刪錯了，比如 limit 500, 那也就丟了 500 條數據，並不致命，通過 binlog 也可以很快恢復數據。
2. 避免了長事務，delete 執行時 MySQL 會將所有涉及的行加寫鎖和 Gap 鎖（間隙鎖），所有 DML 語句執行相關行會被鎖住，如果刪除數量大，會直接影響相關業務無法使用。
3. 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。
你先考慮一下，再看看幾位老鐵的回答：
----
Tony Du：
----
肉山：
不考慮數據表的訪問並發量，單純從這個三個方案來對比的話。
至於選哪一種方案要結合實際場景，綜合考慮各個因素吧，比如表的大小，並發量，業務對此表的依賴程度等。
---
～嗡嗡：
1. 直接 delete 10000 可能使得執行事務時間過長
2. 效率慢點每次循環都是新的短事務，並且不會鎖同一條記錄，重複執行 DELETE 知道影響行為 0 即可
3. 效率雖高，但容易鎖住同一條記錄，發生死鎖的可能性比較高
---
怎麼刪除表的前 10000 行。比較多的朋友都選擇了第二種方式，即：在一個連接中循環執行 20 次 delete from T limit 500。確實是這樣的，第二種方式是相對較好的。
第一種方式（即：直接執行 delete from T limit 10000）裡面，單個語句佔用時間長，鎖的時間也比較長；而且大事務還會導致主從延遲。
第三種方式（即：在 20 個連接中同時執行 delete from T limit 500），會人為造成鎖衝突。
這個例子對我們實踐的指導意義就是，在刪除數據的時候儘量加 limit。這樣不僅可以控制刪除數據的條數，讓操作更安全，還可以減小加鎖的範圍。所以，在 delete 後加 limit 是個值得養成的好習慣。
好了，本文就帶你了解這些，如果有相關疑問和好想法，請在下方留言，方便和小夥伴兒們一起討論。
最近有有不少老鐵在後臺留言說，想進大廠，但是算法不好。最近我整理了一份刷題實錄，這份刷題實錄，也讓我進了心儀的大廠。現在開放分享給大家。希望對大家有所幫助。
任何的算法題，如同寫作文一樣，都有一些模板可以套用的。比如面試常考的DP（動態規劃），難的是一些關鍵點是否能想清楚。比如你能寫出動態轉移方程，這題基本上就可以AC了。
整個刷題實錄內容，包括 雙子針、動態規劃、二分查找、貪心算法、深度優先搜索、字符串、遞歸、字典樹、排序、鍊表等相關專題內容。圖文並茂，附有刷題答案源碼。刷題任務的題目，是根據題目的類型來匯總的，總結了八個類別，每個類別下面也總結了5個左右的題型，幫助大家分門別類的突破，所以刷起來相對會更有重點和針對性。如果從頭到尾的刷，每周按順序刷42題，很容易讓自己堅持不下來，也會覺得很枯燥。所以在制定計劃的時候可以讓這個計劃變得更「有趣"和針對性，讓它看起來更容易實現一點，才會更容易堅持。
目前上述內容已打包成完整電子書，具體獲取方式如下：
掃描關注 Github愛好者社區 公眾號；
在 Github愛好者社區 公眾號後臺回復關鍵詞「9999」獲取下載地址。
掃描關注，回復"9999"即可下載