Insert into select语句引起的生产事故

前言

  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所有记录被锁定的状况。

参考文章

• insert into … select 因为SELECT表引发的死锁状况分析

结尾

  若是以为对你有帮助，能够多多评论，多多点赞哦，也能够到个人主页看看，说不定有你喜欢的文章，也能够随手点个关注哦，谢谢。