江苏龙网

  1. 首页 > 资讯 > 科技 > >

「支付 可以很 ____」同事埋了个坑：Insert into select语句把生产服务器炸了( 二 )

从上面可以发现一开始能正常插入 ， 但是后面突然就卡住了 ， 并且耗费了23s才成功 ， 然后才能继续插入 。 这个时候已经迁移成功了 ， 所以能正常插入了 。
出现的原因 在默认的事务隔离级别下：insert into order_record select * from order_today 加锁规则是：order_record表锁 ， order_today逐步锁（扫描一个锁一个） 。
分析执行过程 。
「支付 可以很 ____」同事埋了个坑：Insert into select语句把生产服务器炸了
本文插图

通过观察迁移sql的执行情况你会发现order_today是全表扫描 ， 也就意味着在执行insert into select from 语句时 ， mysql会从上到下扫描order_today内的记录并且加锁 ， 这样一来不就和直接锁表是一样了 。
这也就可以解释 ， 为什么一开始只有少量用户出现支付失败 ， 后续大量用户出现支付失败 ， 初始化订单失败等情况 ， 因为一开始只锁定了少部分数据 ， 没有被锁定的数据还是可以正常被修改为正常状态 。 由于锁定的数据越来越多 ， 就导致出现了大量支付失败 。 最后全部锁住 ， 导致无法插入订单 ， 而出现初始化订单失败 。
解决方案 由于查询条件会导致order_today全表扫描 ， 什么能避免全表扫描呢 ， 很简单嘛 ， 给pay_success_time字段添加一个idx_pay_suc_time索引就可以了 ， 由于走索引查询 ， 就不会出现扫描全表的情况而锁表了 ， 只会锁定符合条件的记录 。
最终的sqlINSERT INTO order_record SELECT* FROMorder_today FORCE INDEX (idx_pay_suc_time)WHEREpay_success_time <= '2020-03-08 00:00:00'; 执行过程
「支付 可以很 ____」同事埋了个坑：Insert into select语句把生产服务器炸了
本文插图

总结 使用insert into tablA select * from tableB语句时 ， 一定要确保tableB后面的where ， order或者其他条件 ， 都需要有对应的索引 ， 来避免出现tableB全部记录被锁定的情况 。
备份操作更好的方式是dump出sql,改个表名 ， 然后source ， 这样线上直接的sql操作不建议 ， 测试环境玩玩倒没事


推荐阅读


上一篇：「魅力科学君」霍金的4个关系到人类存亡的预言，有两个正在悄悄地变成现实

下一篇：罗永浩：罗永浩为直播翻车道歉：诚意满满