坑！就寫了一行sql，整個系統掛了..(贈書)

做者：不同的科技宅   
出處：juejin.im/post/5e670f0151882549274a65ef

前言

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的數據。模擬線上發生的狀況。

創建表結構

訂單表

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所有記錄被鎖定的狀況。

福利時間

今天民工哥技術之路聯合【北京大學出版社】給你們帶來《Oracle高性能系統架構實戰大全》技術書籍福利，助力你們更好的學習Oracle數據庫技術。

送書規則：公衆號留言說說你的Oracle學習與排障經驗，或者你對數據庫的性能有何獨特的看法，精選留言點贊1-5名讀者各送出一本此書。