別不信，你可能連 MySQL 的 Delete 都不會！

第一時間獲取技術乾貨和業界資訊！

這個話題有點誇張，但其實也是很是現實的問題。你會增刪改查，是否是就會了 MySQL 一個道理。

今天我要說的這個問題是，你會了 MySQL 的 Delete 語法，會寫 delete 語句是否是就必定會刪數據了？咱們先來看一個例子。

假設如今有一張表，須要刪除前 1 萬條數據。有下面三種SQL語句，你會選擇哪個？爲何？

估計不少人會選擇方案1吧。由於，一條 SQL 語句能搞定的事，何須拆開呢？並且平時就是這樣用的。

問題是方案1你在本地，測試環境用並沒什麼毛病。可是若是在生產環境用，你想一想看，這是否是一個長事務，大事務。會不會阻塞其餘的操做？會不會致使系統崩潰？

雖然看起來 SQL 語句沒寫錯。簡單、有效、粗暴，可是，事務相對較長，則佔用鎖的時間較長，會致使其餘客戶端等待資源時間較長。嚴重一些的說，這個操做可能會致使其餘不少操做超時，繼而擴大危害。咱們電商系統就發生過一次相似的事情，客服電話瞬間擠爆！

再說方案2，每次刪除 500 條數據，看起來實現的比較複雜，可是安全，可靠。串行化執行，將相對長的事務分紅屢次相對短的事務，則每次事務佔用鎖的時間相對較短，其餘客戶端在等待相應資源的時間也較短。這樣的操做，同時也意味着將資源分片使用（每次執行使用不一樣片斷的資源），能夠提升併發性。

方案3，開一堆線程。人爲本身製造鎖競爭，加重併發量。多個事務會對同一行產生鎖競爭，消耗cpu資源。CPU 可能會在瞬間飆高。

因此說，不要執拗的認爲 delete 語句很簡單。上面三種方案至於選哪種方案要結合實際場景，綜合考慮各個因素吧，好比表的大小，併發量，業務對此表的依賴程度等。

另外，上面 3 個 delete 語句，咱們平時都不常見。並且平時也不該該這樣寫，刪除數據，要先把 id 找出來，再根據 id 來進行刪除。

面試的時候出這個題：「假設如今有一張表，須要刪除前 1 萬條數據？」，你別一會兒就把方案1直接拿出來。這樣你就死定了，去年咱們就有這樣的面試題，很多人掉坑裏！其實編程最重要的是思考和思想，而不是寫代碼！你是否定同？請留言。最後打個小廣告，想買極客時間學習課程的請加我微信號：xttblog，全部課程都有返現！