MYSQL大表刪除

1. 選場景選策略

• 整張表的資料全部刪除

如果是整張表的資料全部清空、刪除，這種場景倒是非常簡單，TRUNCATE TABLE肯定是最快的。反而用DELETE處理的話，就是一個糟糕的策略。

• 大表中刪除一部分資料

刪除大表中絕大部分的資料，但是這個絕大部分怎麼定義不好量化，所以我們這裡就量化為60%。如果刪除的資料比例超過60%，就採用下面方法：

1. 新 建表TEST_TMP

2. 將要保留的資料轉移到TEST_TMP

3. 將原表TEST重新命名為TEST_OLD， 而將TEST_TMP重新命名為TEST

4. 檢查相關的觸發器、約束，進行觸發器或約束的重新命名

5. 核對操作是否正確後，原表（TEST_OLD）要麼TRUANCATE後，再DROP掉。要麼保留一段時間，保險起見。

刪除大表中部分資料，如果比例不超過60%：

1. 先刪除或禁用無關索引（無關索引，這裡指執行計劃不用到的索引，這裡是指對當前DELETE語句無用的索引）。因為DELETE操作屬於DML操作，而且大表的索引一般也非常大，大量DELETE將會對索引進行維護操作，產生大量額外的IO操作。

2. 用小批量,分批次刪除（批量刪除比一次性刪除效能要快很多）。不要一次性刪除大量資料。一次性刪除大量記錄。會導致鎖的粒度範圍很大，並且鎖定的時間非常長，而且還可能產生阻塞，嚴重影響業務等等。而且資料庫的事務日誌變得非常大。執行的時間變得超長，效能非常糟糕。

2. 準備工作

利用 MYSQL 儲存過程向表中新增大量測試資料，示例：

3. 落地實踐方案

結合本專案的實際，本次選取方案為分批次刪除表中資料，首先查出來滿足條件的表中資料總數，對總數與每次刪除數進行向上取餘，得出需執行 DELETE 次數，最終迴圈執行刪除操作。每次刪除總數結合實際進行選取，本案例選取每次刪除 1 萬條資料。

1. 總數方案1

2. 總數方案2

3. 槽方案

注意：本例中需注意時間非同步問題，應當選取 JAVA8 提供的時間操作類。Calendar 類在使用中需開發者自行解決非同步問題。

引用：https://blog.csdn.net/weixin_42302384/article/details/114587546?utm_term=calendar執行緒安全的&utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2

測試：此次測試分為本地本機測試與遠端資料庫伺服器測試，其中主要考慮因素為本機與伺服器機器效能之間的差異，網路原因不在測試考慮範圍內。

以下測試均是批量刪除，每次刪除資料為 1 萬條（本地本機資料庫）：

億資料刪除十萬

億資料刪除百萬

千萬資料刪除十萬

千萬資料刪除百萬

百萬資料刪除十萬

每次刪除資料為 10 萬條（伺服器資料庫），資料庫最大連線時長3分：

百萬資料刪除十萬

千萬資料刪除十萬

八千萬資料刪除十萬

億資料刪除十萬

引用：

https://www.jb51.net/article/207999.htm

http://c.biancheng.net/mysql/85/

https://www.cnblogs.com/imoing/p/3426324.html

https://www.cnblogs.com/kerrycode/p/12448322.html