22

因用了Insert into select语句,同事被开除了!

 3 years ago
source link: https://zhuanlan.51cto.com/art/202004/615693.htm
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

因用了Insert into select语句,同事被开除了!

Insert into select 请慎用,同事因为使用了 Insert into select 语句引发了重大生产事故,最后被开除。

某天 xxx 接到一个需求,需要将表 A 的数据迁移到表 B 中去做一个备份。他本想通过程序先查询查出来然后批量插入,但 xxx 觉得这样有点慢,需要耗费大量的网络 I/O,决定采取别的方法进行实现。

通过在某度的海洋里遨游,他发现了可以使用 insert into select 实现,这样就可以避免使用网络 I/O,直接使用 SQL 依靠数据库 I/O 完成,这样简直不要太棒,然后他就被开除了。

6e055ba86cce23bd0cdb042a8ef47852.jpg-wh_651x-s_41209947.jpg

事故发生的经过

由于数据数据库中 order_today 数据量过大,当时好像有 700W 了,并且每天在以 30W 的速度增加。

所以上司命令 xxx 将 order_today 内的部分数据迁移到 order_record 中,并将 order_today 中的数据删除,这样来降低 order_today 表中的数据量。

由于考虑到会占用数据库 I/O,为了不影响业务,计划是 9:00 以后开始迁移,但是 xxx 在 8:00 的时候,尝试迁移了少部分数据(1000 条),觉得没啥问题,就开始考虑大批量迁移。

c79f23725d9f7c8affaca3a2a315ebe3.jpg

在迁移的过程中,应急群是先反应有小部分用户出现支付失败,随后反应大批用户出现支付失败的情况,以及初始化订单失败的情况,同时腾讯也开始报警。

d3c112d92f155c65afa24762fb2a0d24.jpg

然后 xxx 就慌了,立即停止了迁移。本以为停止迁移就就可以恢复了,但是并没有。

后面发生的你们可以脑补一下,当时整个支付系统瘫痪了快一个小时,客服电话都被打爆。

事故还原

在本地建立一个精简版的数据库,并生成了 100w 的数据。模拟线上发生的情况。

1. 建立表结构

订单表如下:



  1. CREATE TABLE `order_today` ( 
  2. `id` varchar(32) NOT NULL COMMENT '主键', 
  3. `merchant_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '商户编号', 
  4. `amount` decimal(15,2) NOT NULL COMMENT '订单金额', 
  5. `pay_success_time` datetime NOT NULL COMMENT '支付成功时间', 
  6. `order_status` varchar(10) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '支付状态  S:支付成功、F:订单支付失败', 
  7. `remark` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL COMMENT '备注', 
  8. `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', 
  9. `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间 -- 修改时自动更新', 
  10.   PRIMARY KEY (`id`) USING BTREE, 
  11. KEY `idx_merchant_id` (`merchant_id`) USING BTREE COMMENT '商户编号' 
  12. ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

订单记录表如下:



  1. CREATE TABLE order_record like order_today; 

今日订单表数据如下:

bbaa05d4a6e2c51e3c00ab1e16070b4f.jpg-wh_600x-s_836918065.jpg

2. 模拟迁移

把 8 号之前的数据都迁移到 order_record 表中去:



  1. INSERT INTO order_record SELECT 
  2.     order_today  
  3. WHERE 
  4.     pay_success_time < '2020-03-08 00:00:00'; 

在 Navicat 中运行迁移的 SQL,同时开另个一个窗口插入数据,模拟下单:

9bed8dfd6899afbcba3f542632180afe.jpg-wh_600x-s_2998035278.jpg

fcbb116dca38ff64e7b5ab0b7874447f.jpg-wh_600x-s_1497427918.jpg

从上面可以发现一开始能正常插入,但是后面突然就卡住了,并且耗费了 23s 才成功,然后才能继续插入。这个时候已经迁移成功了,所以能正常插入了。

出现的原因

在默认的事务隔离级别下:insert into order_record select * from order_today 加锁规则是:order_record 表锁,order_today 逐步锁(扫描一个锁一个)。

分析执行过程:

c554b860b4140541c4917ab282756e59.png-wh_600x-s_102070338.png

通过观察迁移 SQL 的执行情况你会发现 order_today 是全表扫描,也就意味着在执行 insert into select from 语句时,MySQL 会从上到下扫描 order_today 内的记录并且加锁,这样一来不就和直接锁表是一样了。

这也就可以解释,为什么一开始只有少量用户出现支付失败,后续大量用户出现支付失败,初始化订单失败等情况,因为一开始只锁定了少部分数据,没有被锁定的数据还是可以正常被修改为正常状态。

由于锁定的数据越来越多,就导致出现了大量支付失败。最后全部锁住,导致无法插入订单,而出现初始化订单失败。

解决方案

由于查询条件会导致 order_today 全表扫描,什么能避免全表扫描呢,很简单嘛,给 pay_success_time 字段添加一个 idx_pay_suc_time 索引就可以了。

由于走索引查询,就不会出现扫描全表的情况而锁表了,只会锁定符合条件的记录。

最终的 SQL:



  1. INSERT INTO order_record SELECT 
  2.     order_today FORCE INDEX (idx_pay_suc_time) 
  3. WHERE 
  4.     pay_success_time <= '2020-03-08 00:00:00'; 

执行过程如下:

1f95d12d9ead332e79af16a8fe077d57.jpg

总结

使用 insert into tablA select * from tableB 语句时,一定要确保 tableB 后面的 where,order 或者其他条件,都需要有对应的索引,来避免出现 tableB 全部记录被锁定的情况。

作者:不一样的科技宅

编辑:陶家龙

出处:https://juejin.im/post/5e670f0151882549274a65ef

06b2a54c97a0c09401603bab7aea68d4.gif-wh_600x-s_2946624692.gif

【编辑推荐】

【责任编辑:赵宁宁 TEL:(010)68476606】

点赞 7


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK