昨天晚上加班到十點多，在公司茶水間跟小李閑聊，突然就聽他說起一個特別離譜的事兒。我們公司有個小伙，剛來沒多久，人特別實在，就是有點軸。結果前兩天因為寫了個“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-

閱讀原文：原文鏈接