事件分析报告

上周三凌晨两点，事件杭州一家做跨境电商的分析小公司里，运维人员发现后台订单数据突然少了三分之一。报告不是事件被删除，是分析查不到了——数据库返回空结果，但磁盘占用没变。报告他第一反应是事件网络抖动，重启了服务，分析没用。报告接着查慢查询日志，事件发现一张核心表的分析索引全部失效，重建索引花了四十分钟，报告数据回来了。事件问题看似解决，分析但没人解释索引为什么集体失效。报告

我后来拿到一份内部复盘记录。真正原因不是数据库本身，而是当天下午一次看似无关的代码上线。开发人员在订单查询接口里加了一个“优化”，把原本走索引的WHERE merchant_id = ? AND status = 1改成了WHERE merchant_id = ? AND status != 0。后者在MySQL里无法有效利用索引，因为!=是否定条件。上线后流量不大，问题没暴露。到了凌晨，定时任务批量拉取数据，全表扫描把连接池占满，索引统计信息被异常刷新，连锁反应导致其他查询也走偏。四十分钟的重建索引只是治标，真正修复是回滚那段代码。

这类事件有个共同点：故障表现和根因之间隔了好几层。运维看到的是索引失效，开发看到的是SQL写法，业务看到的是订单丢失。如果只盯着最上面那层，下次换个写法还会再犯。我见过太多团队在复盘时写“加强监控”“完善流程”，但具体到这次，监控能发现索引失效吗？能，但那是结果。真正该监控的是慢查询比例和全表扫描次数，这两个指标在故障前半小时就有异常波动，只是没人设告警。

另一个细节值得说。这家公司用的云数据库，默认开启自动索引优化。这个功能本意是好的，但它有个特性：当检测到大量全表扫描时，会尝试重建索引。问题是重建期间会锁表，而锁表又加剧了连接堆积。自动优化反而放大了故障。这不是云厂商的错，是使用者没搞清楚这个开关的边界条件。技术选型时只看功能列表，不看失效模式，迟早要还债。

从人的角度看，凌晨两点值班的运维同学做了他能做的一切。重启、查日志、重建索引，每一步都合理。但他没权限回滚代码，也没权限改数据库参数。等他联系上开发，已经过去二十分钟。这不是个人能力问题，是组织设计问题。小公司往往一个人扛所有，但故障响应需要的是并行处理：一个人查数据库，一个人查最近上线，一个人准备回滚。串行操作在凌晨就是灾难。

我自己的判断是，这类“索引失效”事件在中小团队里会越来越频繁。原因不复杂：开发人员对SQL性能的敏感度在下降。ORM框架用多了，写!=和写=在代码层面没区别，跑起来才知道。加上云数据库把底层屏蔽得越来越好，很多人已经不知道执行计划长什么样。这不是倒退，是分工细化的代价。但代价不能总让运维扛。

如果要给一个可操作的建议，就一条：在代码合并前，强制跑一遍慢查询检测。不用多复杂，把新SQL在测试库上执行，看EXPLAIN结果里type是不是ALL。是就拦下来。这个动作花不了五分钟，但能拦住八成类似问题。剩下的两成，靠值班手册里写清楚“先查最近上线，再查数据库”。顺序错了，时间就没了。

事件报告写到这，其实没有结论。故障修好了，代码回滚了，复盘会开过了。但下次换个条件，换个表，同样的剧本还会上演。技术世界里的因果链，从来不是线性的。