昨天晚上加班到十点多，在公司茶水间跟小李闲聊，突然就听他说起一个特别离谱的事儿。我们公司有个小伙，刚来没多久，人特别实在，就是有点轴。结果前两天因为写了个“insert into ... select ...”被老板叫去谈话，最后直接给开了，真不是开玩笑。我一听也懵圈，这不就是个最基础的SQL操作么，咋就能被开除呢，真有点摸不着头脑。

小伙干了啥

其实事情也简单，就是他在生产库上直接写了个这样的大SQL：

insert into big_table_archive
select * from big_table
where update_time < '2024-01-01';

你们说是不是，光看没啥毛病，业务意思也清楚，就是把老数据归档走。可问题是，这表可不是那种一天几百条的小破表，是公司最核心的交易流水表，一天几百万数据。小伙这一条下来，整个生产库直接卡死，后面的订单、支付、消息队列，连带着接口都全挂了，公司大群直接炸了，运营、测试全在问怎么回事，现场一片混乱。最后还是DBA连夜干预，回滚才算稳住。老板第二天火冒三丈，直接让HR办了手续。

其实啊，insert into select 这玩意本身没错，但就怕啥都不懂，真用在生产环境，一没评估量级，二没加任何limit分批、没锁表、没走任何流程就直接上线，谁顶得住？公司不是怕你写SQL，是怕你啥都不问，直接怼生产数据库，这种风险操作，伤不起！

Java后台哥几个，踩过坑吗

说实话，我自己之前刚转Java后端的时候，也栽过这种跟SQL相关的坑。记得有次要清理表，用MyBatis直接写了个delete from ... where ...，结果发现其实还有其他业务也在用，删掉后领导脸都黑了。所以后来我们组里都养成习惯，凡是涉及到大量数据变动的操作，不管啥场景，哪怕是测试环境，也先让DBA过一眼，业务方、运维得都知道。

现在一般都怎么搞呢？比如你要归档，都会像下面这样，分批搞：

public void archiveOldData() {
    int batchSize = 1000;
    while (true) {
        int count = jdbcTemplate.update(
            "insert into big_table_archive select * from big_table where update_time < ? limit ?",
            oldDate, batchSize
        );
        if (count == 0) break;
        jdbcTemplate.update(
            "delete from big_table where update_time < ? limit ?",
            oldDate, batchSize
        );
    }
}

你看，分批搞，每次搬一点，压力小多了。实在怕，也可以搞成异步任务，夜里跑，跑之前还会先测一遍慢SQL、锁表情况，写个预案。连数据归档都要走审批流程，这已经是行业共识。

为啥会被开，真是SQL的锅？

其实归根结底，不是说insert into select不能用，而是你不能啥都不懂就直接怼生产。这种大表批量操作，牵一发而动全身，风险太大，哪怕技术再牛，心态再稳，也不能拿公司生产环境当练手。要是早问一句“哥们，这表能直接归档吗？要不先走测试？”也不至于被开。

你们可别笑，这种事真的不是个例。还有很多新手，喜欢一口气把所有数据批量处理掉，结果遇到锁表、死锁、回滚、索引失效，各种幺蛾子。生产数据库跟你本地开发库，不是一个量级的东西，有时候一次失误就是全公司陪你“玩命”。

突然想起前天楼下抽烟那会，运维还跟我聊，隔壁公司去年有个新人，insert语句加了个忘记带where条件，几千万数据全都搞没了，最后也是一样的结局。你说，这事儿要说是技术问题，不如说是态度和流程问题。

唉，说着说着有点感慨，现在但凡正规点的公司，都会把这种“敏感操作必须审批”写进流程里。兄弟们要是以后再遇到这种场景，记得别逞能，啥事都跟大伙打个招呼，能分批分库分表就别一刀切。

反正最后记住一句话，insert into select不是原罪，拍脑袋写在生产环境才是。技术都是细节，流程才是护身符，真的。

-END-

阅读原文：原文链接