前言
Insert into select请慎用。java
这天xxx接到一个需求，须要将表A的数据迁移到表B中去作一个备份。本想经过程序先查询查出来而后批量插入。mysql
但xxx以为这样有点慢，须要耗费大量的网络I/O，决定采起别的方法进行实现。面试
经过在Baidu的海洋里遨游，他发现了可使用insert into select实现，这样就能够避免使用网络I/O，直接使用SQL依靠数据库I/O完成，这样简直不要太棒了。sql
而后他就被开除了。数据库
事故发生的通过。
因为数据数据库中order_today数据量过大，当时好像有700W了而且天天在以30W的速度增长。微信
因此上司命令xxx将order_today内的部分数据迁移到order_record中，并将order_today中的数据删除。网络
这样来下降order_today表中的数据量。post
因为考虑到会占用数据库I/O，为了避免影响业务，计划是9:00之后开始迁移，可是xxx在8:00的时候，尝试迁移了少部分数据(1000条)，以为没啥问题，就开始考虑大批量迁移。优化
在迁移的过程当中，应急群是先反应有小部分用户出现支付失败，随后反应大批用户出现支付失败的状况，以及初始化订单失败的状况，同时腾讯也开始报警。spa
而后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索引就能够了。
因为走索引查询，就不会出现扫描全表的状况而锁表了，只会锁定符合条件的记录。
关于 MySQL 索引的详细用法有实战，你们能够看我之前的索引优化系列的文章。
最终的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所有记录被锁定的状况。
结尾
若是以为对你有帮助，能够点个在看，点赞哦，谢谢。
来源：juejin.im/post/6844904086173646862
暖心老哥，在这里给你们整理了2020年最新java面试题，涵盖java各个技术领域，快上万道了，须要的小伙伴能够领取一下，免费的，助你们找到一份满意的工做
本文分享自微信公众号 - IT老哥（dys_family）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。