因用了Insert into select語句，公司報警了
來源：https://mp.weixin.qq.com/s/2IbviMaQoD5gJ7uZWojr_w
Insert into select請慎用。這天xxx接到一個需求，需要將表A的資料遷移到表B中去做一個備份。本想通過程式先查詢查出來然後批量插入。但xxx覺得這樣有點慢，需要耗費大量的網路I/O，決定採取別的方法進行實現。
通過在Baidu的海洋裡遨遊，她發現了可以使用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的資料。模擬線上發生的情況。
# 建立表結構
訂單表
CREATETABLE`order_today`(`id`varchar(32)NOTNULLCOMMENT'主鍵',`merchant_id`varchar(32)CHARACTERSETutf8COLLATEutf8_general_ciNOTNULLCOMMENT'商戶編號',`amount`decimal(15,2)NOTNULLCOMMENT'訂單金額',`pay_success_time`datetimeNOTNULLCOMMENT'支付成功時間',`order_status`varchar(10)CHARACTERSETutf8COLLATEutf8_general_ciNOTNULLCOMMENT'支付狀態S：支付成功、F：訂單支付失敗',`remark`varchar(100)CHARACTERSETutf8COLLATEutf8_general_ciDEFAULTNULLCOMMENT'備註',`create_time`timestampNOTNULLDEFAULTCURRENT_TIMESTAMPCOMMENT'建立時間',`update_time`timestampNOTNULLDEFAULTCURRENT_TIMESTAMPONUPDATECURRENT_TIMESTAMPCOMMENT'修改時間--修改時自動更新',PRIMARYKEY(`id`)USINGBTREE,KEY`idx_merchant_id`(`merchant_id`)USINGBTREECOMMENT'商戶編號')ENGINE=InnoDBDEFAULTCHARSET=utf8;
訂單記錄表
CREATETABLEorder_recordlikeorder_today;
今日訂單表資料
#模擬遷移
把8號之前的資料都遷移到order_record表中去。
INSERT INTO order_record SELECT*FROMorder_todayWHEREpay_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*FROMorder_today FORCE INDEX (idx_pay_suc_time)WHEREpay_success_time <= '2020-03-08 00:00:00';
執行過程
# 總結
使用insert into tablA select * from tableB語句時，一定要確保tableB後面的where，order或者其他條件，都需要有對應的索引，來避免出現tableB全部記錄被鎖定的情況。
參考
-
https://blog.csdn.net/asdfsadfasdfsa/article/details/83030011