江苏龙网

  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 索引就可以了 。
由于走索引查询 ， 就不会出现扫描全表的情况而锁表了 ， 只会锁定符合条件的记录 。
最终的 SQL：INSERT 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 全部记录被锁定的情况 。


推荐阅读


上一篇：「设计」太好了，发现一种“隐藏”的对称，能为超材料的设计开辟新途径

下一篇：「美好，一直在身边」websocket连接太多导致服务器卡顿怎么办？一招轻松实现横向扩展