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;
