Insert into select 請慎用，同事因爲使用了 Insert into select 語句引發了重大生產事故，最後被開除。
某天 xxx 接到一個需求，需要將表 A 的數據遷移到表 B 中去做一個備份。他本想通過程序先查詢查出來然後批量插入，但 xxx 覺得這樣有點慢，需要耗費大量的網絡 I/O，決定採取別的方法進行實現。
通過在某度的海洋裏遨遊，他發現了可以使用 insert into select 實現，這樣就可以避免使用網絡 I/O，直接使用 SQL 依靠數據庫 I/O 完成，這樣簡直不要太棒，然後他就被開除了。
事故發生的經過
由於數據數據庫中 order_today 數據量過大，當時好像有 700W 了，並且每天在以 30W 的速度增加。
所以上司命令 xxx 將 order_today 內的部分數據遷移到 order_record 中，並將 order_today 中的數據刪除，這樣來降低 order_today 表中的數據量。
由於考慮到會佔用數據庫 I/O，爲了不影響業務，計劃是 9：00 以後開始遷移，但是 xxx 在 8：00 的時候，嘗試遷移了少部分數據（1000 條），覺得沒啥問題，就開始考慮大批量遷移。
在遷移的過程中，應急羣是先反應有小部分用戶出現支付失敗，隨後反應大批用戶出現支付失敗的情況，以及初始化訂單失敗的情況，同時騰訊也開始報警。
然後 xxx 就慌了，立即停止了遷移。本以爲停止遷移就就可以恢復了，但是並沒有。
後面發生的你們可以腦補一下，當時整個支付系統癱瘓了快一個小時，客服電話都被打爆。
事故還原
在本地建立一個精簡版的數據庫，並生成了 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_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;```python
分別對202，304，404狀態重新取樣，並放在一個列表裏面
req_df_lis = [
log_df2[log_df2.Status == 200].Request.resample("H").sum().fillna(0),
log_df2[log_df2.Status == 304].Request.resample("H").sum().fillna(0),
log_df2[log_df2.Status == 404].Request.resample("H").sum().fillna(0)
]
# 將三個dataframe組合起來
req_df = pd.concat(req_df_lis,axis=1)
req_df.columns = ["200", "304", "404"]
# 繪圖
req_df.plot(figsize=(16,10))
訂單記錄表如下：
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 全部記錄被鎖定的情況。