江苏龙网

  1. 首页 > 人文 > >

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


出现的原因 在默认的事务隔离级别下：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 select语句把生产服务器炸了
本文插图
总结 使用insert into tablA select * from tableB语句时 ， 一定要确保tableB后面的where ， order或者其他条件 ， 都需要有对应的索引 ， 来避免出现tableB全部记录被锁定的情况 。
备份操作更好的方式是dump出sql,改个表名 ， 然后source ， 这样线上直接的sql操作不建议 ， 测试环境玩玩倒没事


推荐阅读


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

下一篇：#主战坦克#南亚次大陆上的新霸主，VT-4主战坦克！