半夜三点四十。公司群里静悄悄的，就我一人对着这个祖传跑批系统的日志发呆。客户是某个银行，周一一早要报表，周五晚上我把新需求提上去，周六下午开始报错，到现在——凌晨三点多——还没跑通。
具体错在哪儿？报错信息就一行：Fatal error: Uncaught PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away。看到这个我脑子第一反应是：又是连接超时。当年写这套跑批的老张早跳槽了，代码里所有长事务都用一个连接从头跑到尾，中间没有任何重连逻辑。这毛病不是一天两天了，之前都是绕过去，重启一下MySQL、把 wait_timeout 改大点就能糊弄过去，但这次……改了也没用。
我仔细翻了翻日志，发现这次跑批卡在某个中间表上——一个几千万行的临时表，干活的 SQL 是一个嵌套了六层的子查询。不是我写的，是老张留下的。我盯着那段 SQL 看了半天，觉得脑子嗡嗡的。平时我自认对这套祖传代码门儿清，可半夜三点，咖啡喝到第三杯，眼皮子打架的时候，这种六层嵌套的玩意儿看一遍忘一遍。改一次跑一次，跑一次挂一次，光是在那儿数括号我就数了二十分钟。
话说回来，当时我其实已经用了一年了那个 Cursor。白天在公司我从来不说，顶多说“让那玩意儿帮着补补括号”，有时候组里的新人在那儿吹 Copilot 多好用，我心里想的是：哼，你们那叫用？我那才叫用。可那天晚上，我是真有点扛不住了。本来不打算用它，自己硬啃，但凌晨四点的时候，我实在不想自己数那六个括号了，就把那段 SQL 和报错日志一股脑黏了进去，让它帮忙看看。
结果它很快指出一个问题：有个子查询里面，是老张把一张归档表的年份字段写错了，导致索引失效，全表扫完后结果集太大，内存直接爆了，连带着把 MySQL 连接也挤断。我说呢，之前我老是盯着连接超时那个方向修，就没想过这条 SQL 本身就有毛病。
我照着它的思路改了一版，改成临时表分步查，跑批居然真过了。时间刚好凌晨五点二十，天都蒙蒙亮了。系统跑完，报表数据都对上了。
我合上电脑，躺在工位椅上，看着天花板缓了半天。说不上是爽还是气——一面是“终于干完了”的解脱，一面是“这破毛病居然让个 AI 一眼看穿”的别扭。我总不能承认我靠它才搞定吧。熬了一宿的是我，查了半天日志的是我，它只不过……帮我数了数括号。对，打打下手而已。
回去路上我在地铁上又想了想，其实那玩意儿确实有两下子。但这句话我谁都不会说。明天万一有人问起这事儿，我就说：“数据库参数的问题，改了几行代码，重启了一下就好了。”反正也没人问那么细。
话说回来，老张当年写这段东西的时候，估计也没想到自己会把年份写错。算了，人都走了，说这个也没意思。睡觉去了。