共計 2593 個字符，預計需要花費 7 分鐘才能閱讀完成。

這篇文章將為大家詳細講解有關使用 Insert into select 語句把用戶訂單全鎖了該怎么辦，文章內容質量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

前言

Insert into select 請慎用。這天同事接到一個需求，需要將表 A 的數據遷移到表 B 中去做一個備份。本想通過程序先查詢查出來然后批量插入。但 xxx 覺得這樣有點慢，需要耗費大量的網絡 I /O，決定采取別的方法進行實現。通過在 Baidu 的海洋里遨游，他發現了可以使用 insert into select 實現，這樣就可以避免使用網絡 I /O，直接使用 SQL 依靠數據庫 I / O 完成，這樣簡直不要太棒了。然后他就被開除了。

事故發生的經過

由于數據庫中 order_today 數據量過大，當時好像有 700W 了并且每天在以 30W 的速度增加。所以上司命令同事將 order_today 內的部分數據遷移到 order_record 中，并將 order_today 中的數據刪除。這樣來降低 order_today 表中的數據量。

由于考慮到會占用數據庫 I /O，為了不影響業務，計劃是 9:00 以后開始遷移，但是同事在 8:00 的時候，嘗試遷移了少部分數據 (1000 條)，覺得沒啥問題，就開始考慮大批量遷移。

  在遷移的過程中，應急群是先反應有小部分用戶出現支付失敗，隨后反應大批用戶出現支付失敗的情況，以及初始化訂單失敗的情況，同時騰訊也開始報警。

  然后同事就慌了，立即停止了遷移。

本以為停止遷移就就可以恢復了，但是并沒有。后面發生的你們可以腦補一下。

事故還原

在本地建立一個精簡版的數據庫，并生成了 100w 的數據。模擬線上發生的情況。

建立表結構

訂單表

CREATE TABLE `order_today` ( `id` varchar(32) NOT NULL COMMENT  主鍵 , `merchant_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT  商戶編號 , `amount` decimal(15,2) NOT NULL COMMENT  訂單金額 , `pay_success_time` datetime NOT NULL COMMENT  支付成功時間 , `order_status` varchar(10) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT  支付狀態  S：支付成功、F：訂單支付失敗 , `remark` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL COMMENT  備注 , `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT  創建時間 , `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT  修改時間  --  修改時自動更新 , PRIMARY KEY (`id`) USING BTREE, KEY `idx_merchant_id` (`merchant_id`) USING BTREE COMMENT  商戶編號  ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

訂單記錄表

CREATE TABLE order_record like order_today;

今日訂單表數據

模擬遷移

把 8 號之前的數據都遷移到 order_record 表中去。

INSERT INTO order_record SELECT * FROM order_today WHERE pay_success_time    2020-03-08 00:00:00

在 navicat 中運行遷移的 sql, 同時開另個一個窗口插入數據，模擬下單。

從上面可以發現一開始能正常插入，但是后面突然就卡住了，并且耗費了 23s 才成功，然后才能繼續插入。這個時候已經遷移成功了，所以能正常插入了。

出現的原因

在默認的事務隔離級別下：insert into order_record select * from order_today 加鎖規則是：order_record 表鎖，order_today 逐步鎖（掃描一個鎖一個）。

分析執行過程。

通過觀察遷移 sql 的執行情況你會發現 order_today 是全表掃描，也就意味著在執行 insert into select from 語句時，mysql 會從上到下掃描 order_today 內的記錄并且加鎖，這樣一來不就和直接鎖表是一樣了。

這也就可以解釋，為什么一開始只有少量用戶出現支付失敗，后續大量用戶出現支付失敗，初始化訂單失敗等情況，因為一開始只鎖定了少部分數據，沒有被鎖定的數據還是可以正常被修改為正常狀態。由于鎖定的數據越來越多，就導致出現了大量支付失敗。最后全部鎖住，導致無法插入訂單，而出現初始化訂單失敗。

解決方案

由于查詢條件會導致 order_today 全表掃描，什么能避免全表掃描呢，很簡單嘛，給 pay_success_time 字段添加一個 idx_pay_suc_time 索引就可以了，由于走索引查詢，就不會出現掃描全表的情況而鎖表了，只會鎖定符合條件的記錄。

最終的 sql

INSERT INTO order_record SELECT * FROM order_today FORCE INDEX (idx_pay_suc_time) WHERE pay_success_time  =  2020-03-08 00:00:00

執行過程

總結

使用 insert into tablA select * from tableB 語句時，一定要確保 tableB 后面的 where，order 或者其他條件，都需要有對應的索引，來避免出現 tableB 全部記錄被鎖定的情況。

關于使用 Insert into select 語句把用戶訂單全鎖了該怎么辦就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。