小伙在公司用了个 insert into select 居然被开除了

2025-10-10

兄弟们，上周四凌晨三点，手机疯狂震动，打开工作群一看，运维总监发了条消息："紧急！支付系统大面积失败，所有订单初始化超时！" 我瞬间清醒，光着脚冲进书房打开电脑。

登录服务器一看，数据库连接池已经爆了，慢查询日志里密密麻麻全是 INSERT INTO ... SELECT 语句。顺着代码回溯，发现是新来的实习生小王写的定时任务。这哥们儿为了图省事，直接用 insert into select 迁移支付流水表，结果把整个数据库锁死了。第二天早上，HR 找他谈话，下午他就背着电脑包离开了公司。

这个故事告诉我们：数据库操作一时爽，锁表火葬场。今天咱们就来聊聊这个让小王丢了饭碗的 insert into select，看看它到底有什么魔力，能让程序员分分钟变成 "背锅侠"。

一、insert into select 到底干了什么？

1. 看似优雅的 SQL 背后

insert into select 语法看起来很美好：一行代码搞定数据迁移，不用写循环，不用处理网络 IO，直接让数据库自己干活。但在 MySQL 里，这货的真实面目其实是个 "锁表狂魔"。

举个栗子：假设你有一张 order_today 表，每天新增 30 万条数据，现在需要把旧数据迁移到 order_record。小王写的 SQL 是这样的：

复制

INSERT INTO order_record (order_id, amount, status) SELECT order_id, amount, status FROM order_today WHERE pay_time < 2023-01-01;1.2.3.

看起来没毛病对吧？但实际执行的时候，MySQL 会对 order_today 表进行全表扫描，并且逐条加锁。如果这张表有 700 万条数据，那数据库就像被绑了手脚的武林高手，只能慢慢爬。

2. 锁表的连环暴击

在默认的 RR（可重复读）隔离级别下，insert into select 会触发两种锁：

表锁：对目标表（order_record）加 IX 锁，阻止其他事务对表结构的修改。行锁 + 间隙锁：对源表（order_today）扫描到的每一行加 S 锁，并且锁住行之间的间隙。这就像在高速公路上设置了无数个收费站，后面的车辆（其他事务）只能排队等待。

更坑爹的是，如果源表没有合适的索引，全表扫描会导致锁表时间长达几十分钟。这期间，任何对 order_today 的写操作都会被阻塞，比如用户支付时更新订单状态，就会直接超时失败。

二、为什么测试环境没出问题？

小王在测试的时候，用 1000 条数据模拟了迁移过程，一切正常。但到了生产环境，700 万条数据直接把数据库干趴下了。这是因为：

数据量差异：测试环境的数据量太小，锁表时间短，问题被掩盖了。业务压力不同：生产环境的并发请求量远高于测试，锁冲突更容易爆发。隔离级别差异：有些测试环境可能使用 RC（读已提交）隔离级别，锁机制不同，导致问题不重现。

就像你在健身房举 5 公斤哑铃没问题，但突然换成 50 公斤，肯定会闪到腰。数据库也一样，没有金刚钻，别揽瓷器活。

三、数据库的锁机制：程序员的坟场

1. 锁的类型：从表锁到行锁的千层套路

表锁：简单粗暴，直接锁整个表，性能最差。行锁：只锁需要的行，但在 RR 隔离级别下，可能升级为间隙锁。间隙锁（Gap Lock）：锁住两个行之间的间隙，防止幻读。比如表中有 id=1 和 id=3 的记录，间隙锁会锁住（1,3）这个区间，阻止插入 id=2 的记录。Next-Key 锁：行锁 + 间隙锁的组合，是 MySQL 在 RR 隔离级别下的默认锁策略。

举个栗子：如果表中有 id=1、3、5 三条记录，执行 SELECT * FROM table WHERE id > 2 FOR UPDATE，MySQL 会锁住（2,3]、（3,5]、（5, +∞）这三个区间，防止其他事务插入 id=4 或 6 的记录。

2. 事务隔离级别的坑

MySQL 默认使用 RR 隔离级别，这本来是为了保证可重复读，但也带来了锁表的副作用。如果换成 RC 隔离级别，虽然锁冲突会减少，但可能引发不可重复读的问题。比如，在一个事务中两次查询同一条记录，结果可能不同，因为中间被其他事务修改了。

这就像在电影院看电影，RR 隔离级别是给你单独开了个包间，其他人不能进来；而 RC 隔离级别是大家坐在一起，可能有人中途换座位，导致你看到的画面不一样。

四、如何优雅地迁移数据？

1. 索引优化：给数据库装个 GPS

最直接的解决办法是给 WHERE 条件字段加索引。比如在 order_today.pay_time 上创建索引，这样 SELECT 语句就不会全表扫描，锁的范围也会大大缩小。

复制

ALTER TABLE order_today ADD INDEX idx_pay_time (pay_time);1.

加了索引后，MySQL 就像有了 GPS，能直接定位到需要迁移的数据，而不是在整个数据库里瞎转悠。

2. 分批次迁移：蚂蚁搬家更安全

如果数据量太大，即使有索引，一次性迁移还是可能导致锁表。这时候可以分批处理，每次迁移 1 万条数据，中间提交事务释放锁。

复制

// Java 代码示例 int batchSize = 10000; LocalDateTime startTime = LocalDateTime.of(2023, 1, 1, 0, 0); while (true) { List<Order> orders = orderDao.queryByPayTime(startTime, batchSize); if (orders.isEmpty()) { break; } orderDao.batchInsert(orders); startTime = orders.get(orders.size() - 1).getPayTime().plusSeconds(1); }1.2.3.4.5.6.7.8.9.10.11.12.

这种方法就像蚂蚁搬家，虽然慢一点，但不会把数据库压垮。

3. 使用 MyBatis 的批量插入

MyBatis 提供了多种批量插入策略，比如 ExecutorType.BATCH，可以显著减少数据库交互次数。

复制

SqlSession session = sqlSessionFactory.openSession(ExecutorType.BATCH); OrderMapper mapper = session.getMapper(OrderMapper.class); for (Order order : orders) { mapper.insert(order); } session.commit(); session.close();1.2.3.4.5.6.7.

这种方法比逐条插入快得多，但要注意内存占用，避免 OOM。

4. 存储过程：让数据库自己干活

如果迁移逻辑复杂，可以考虑使用存储过程。存储过程在数据库服务器上执行，减少网络传输，同时可以利用事务控制锁的范围。

复制

DELIMITER // CREATE PROCEDURE migrate_orders() BEGIN DECLARE done INT DEFAULT FALSE; DECLARE order_id BIGINT; DECLARE cur CURSOR FOR SELECT id FROM order_today WHERE pay_time < 2023-01-01; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE; OPEN cur; REPEAT FETCH cur INTO order_id; IF NOT done THEN INSERT INTO order_record (order_id, amount, status) SELECT order_id, amount, status FROM order_today WHERE id = order_id; END IF; UNTIL done END REPEAT; CLOSE cur; END // DELIMITER ;1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.

存储过程就像给数据库写了个 "脚本"，让它自己按步骤执行，减少对应用服务器的压力。

五、最佳实践：避免踩坑的十条军规

永远不要在生产环境直接执行未经测试的 SQL：尤其是 INSERT INTO ... SELECT 这种危险操作。给 WHERE 条件字段加索引：避免全表扫描和锁表。分批次处理大数据量：每次处理 1 万条左右，提交事务释放锁。监控慢查询日志：及时发现执行时间过长的 SQL。使用事务控制锁的范围：避免长时间持有锁。在测试环境模拟生产数据量：不要用小数据量测试来欺骗自己。了解数据库的锁机制：尤其是 RR 隔离级别的 Next-Key 锁。优先使用批量插入工具：如 MyBatis 的批量插入、Spring Batch 等。设置合理的超时时间：防止事务长时间阻塞。做好回滚预案：万一出问题，能快速恢复数据。

六、总结：数据库操作的生死线

小王的故事告诉我们，数据库操作是把双刃剑，用好了能提高效率，用不好就是 "自杀式攻击"。insert into select 本身并没有错，但在不恰当的场景下使用，就会变成 "程序员的坟场"。

作为开发者，我们需要敬畏数据库，了解它的脾气和底线。每次写 SQL 的时候，都要想想："这行代码会不会锁表？有没有更好的方法？" 只有这样，才能避免成为下一个被开除的 "小王"。

阅读剩余

THE END