這天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
表中去。
在navicat中運作遷移的sql,同時開另個一個視窗插入資料，模拟下單。這篇《
如何快速安全的插入千萬條資料？》推薦看下。
從上面可以發現一開始能正常插入，但是後面突然就卡住了，并且耗費了23s才成功，然後才能繼續插入。這個時候已經遷移成功了，是以能正常插入了。
出現的原因
在預設的事務隔離級别下：insert into order_record select * from order_today 加鎖規則是：order_record表鎖，order_today逐漸鎖（掃描一個鎖一個）。MySQL 四種隔離級别，推薦看下。
分析執行過程。
通過觀察遷移sql的執行情況你會發現order_today是全表掃描，也就意味着在執行insert into select from 語句時，mysql會從上到下掃描order_today内的記錄并且加鎖，這樣一來不就和直接鎖表是一樣了。
這也就可以解釋，為什麼一開始隻有少量使用者出現支付失敗，後續大量使用者出現支付失敗，初始化訂單失敗等情況，因為一開始隻鎖定了少部分資料，沒有被鎖定的資料還是可以正常被修改為正常狀态。
由于鎖定的資料越來越多，就導緻出現了大量支付失敗。最後全部鎖住，導緻無法插入訂單，而出現初始化訂單失敗。
解決方案
由于查詢條件會導緻order_today全表掃描，什麼能避免全表掃描呢，很簡單嘛，給pay_success_time字段添加一個idx_pay_suc_time索引就可以了，由于走索引查詢，就不會出現掃描全表的情況而鎖表了，隻會鎖定符合條件的記錄。
關于 MySQL 索引的詳細用法有實戰，大家可以關注公衆号Java技術棧在背景回複mysql擷取系列幹貨文章。
執行過程
總結
使用insert into tablA select * from tableB語句時，一定要確定tableB後面的where，order或者其他條件，都需要有對應的索引，來避免出現tableB全部記錄被鎖定的情況。
參考文章
insert into … select 由于SELECT表引起的死鎖情況分析：
https://blog.csdn.net/asdfsadfasdfsa/article/details/83030011結尾
如果覺得對你有幫助，可以多多評論，多多點贊哦，謝謝。