2020年Java原创口试题库连载中
【000期】Java最全面试题库思维导图
【001期】JavaSE口试题（一）：面向工具
【002期】JavaSE口试题（二）：基本数据类型与访问润色符
【003期】JavaSE口试题（三）：JavaSE语法（1）
【004期】JavaSE口试题（四）：JavaSE语法（3）
【005期】JavaSE口试题（五）：String类
【006期】JavaSE口试题（六）：泛型
【007期】JavaSE口试题（七）：非常
【008期】JavaSE口试题（八）：凑集之List
【009期】JavaSE口试题（九）：凑集之Set
【010期】JavaSE口试题（十）：凑集之Map
【011期】JavaSE口试题（十一）：多线程（1）
【012期】JavaSE口试题（十二）：多线程（2）
【013期】JavaSE口试题（十三）：多线程（3）
【014期】JavaSE口试题（十四）：基本IO流
【015期】JavaSE口试题（十五）：网络IO流
【016期】JavaSE口试题（十六）：反射
【017期】JavaSE口试题（十七）：JVM之内存模型
【018期】JavaSE口试题（十八）：JVM之垃圾回收
【020期】JavaSE系列口试题汇总（共18篇）
【019期】JavaWeb口试题（一）：JDBC
【021期】JavaWeb口试题（二）：HTTP协议
【022期】JavaWeb口试题（三）：Cookie和Session
【023期】JavaWeb口试题（四）：JSP
【024期】JavaWeb口试题（五）：Filter和Listener
【025期】Java工具口试题（一）：版本掌握工具
【026期】Java工具口试题（二）：项目管理工具
【027期】Java设计模式口试题
【028期】JavaWeb系列口试题汇总（共10篇）
【029期】JavaEE口试题（一）Web运用做事器
【030期】JavaEE口试题（二）SpringMVC
【031期】JavaEE口试题（三）Spring（1）
【032期】JavaEE口试题（四）Spring（2）
【033期】JaveEE口试题（五）MyBatis
【034期】JavaEE口试题（六）Hibernate
【035期】JavaEE口试题（七）SpringBoot（1）
更多内容，点击上面蓝字查看
Insert into select请慎用。这天xxx接到一个需求，须要将表A的数据迁移到表B中去做一个备份。本想通过程序先查询查出来然后批量插入。但xxx以为这样有点慢，须要耗费大量的网络I/O，决定采纳别的方法进行实现。通过在Baidu的海洋里遨游，她创造了可以利用insert into select实现，这样就可以避免利用网络I/O，直策应用SQL依赖数据库I/O完成，这样切实其实不要太棒了。然后她就被开除了。
事件发生的经由。
由于数据数据库中order_today数据量过大，当时彷佛有700W了并且每天在以30W的速率增加。以是上司命令xxx将order_today内的部分数据迁移到order_record中，并将order_today中的数据删除。这样来降落order_today表中的数据量。
由于考虑到会占用数据库I/O，为了不影响业务，操持是9:00往后开始迁移，但是xxx在8:00的时候，考试测验迁移了少部分数据(1000条)，以为没啥问题，就开始考虑大批量迁移。
在迁移的过程中，应急群是先反应有小部分用户涌现支付失落败，随后反应大批用户涌现支付失落败的情形，以及初始化订单失落败的情形，同时腾讯也开始报警。
然后xxx就慌了，立即停滞了迁移。
本以为停滞迁移就就可以规复了，但是并没有。后面发生的你们可以脑补一下。
# 事件还原
在本地建立一个精简版的数据库，并天生了100w的数据。仿照线上发生的情形。
# 建立表构造
订单表
CREATE TABLE `order_today` (`id` varchar(32) NOT COMMENT '主键',`merchant_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT COMMENT '商户编号',`amount` decimal(15,2) NOT COMMENT '订单金额',`pay_success_time` datetime NOT COMMENT '支付成功韶光',`order_status` varchar(10) CHARACTER SET utf8 COLLATE utf8_general_ci NOT COMMENT '支付状态 S：支付成功、F：订单支付失落败',`remark` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT COMMENT '备注',`create_time` timestamp NOT DEFAULT CURRENT_TIMESTAMP COMMENT '创建韶光',`update_time` timestamp NOT 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索引就可以了，由于走索引查询，就不会涌现扫描全表的情形而锁表了，只会锁定符合条件的记录。
终极的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全部记录被锁定的情形。
# 参考
https://blog.csdn.net/asdfsadfasdfsa/article/details/83030011
作者：不一样的科技宅
来源：juejin.im/post/5e670f0151882549274a65ef
之前，给大家发过三份Java口试宝典，这次新增了一份，目前统共是四份口试宝典，相信在跳槽前一个月按照口试宝典准备准备，基本没大问题。
《java口试宝典5.0》(初中级)
《350道Java口试题：整理自100+公司》（中高等）
《资深java口试宝典-视频版》（资深）
《Java[BAT]口试必备》（资深）
分别适用于初中级，中高等，资深级工程师的口试复习。
内容包含java根本、javaweb、mysql性能优化、JVM、锁、百万并发、行列步队，高性能缓存、反射、Spring百口桶事理、微做事、Zookeeper、数据构造、限流熔断降级等等。
看到这里，证明有所收成
