一、事故背景与现象

时间范围

• 2022年2月3日 18:11~18:43（历时32分钟）

受影响系统

系统名称	角色	影响范围
dc3	订单数据库主库	订单生成、事务回滚
dc4	订单数据库从库	数据同步、容灾切换

业务影响

• 核心业务：手机点餐、C扫B支付订单无法推送至POS系统，购物车初始化失败
• 用户指标：下单成功率下跌至85%（基线99.9%）
• 技术指标：

  • 数据库主库CPU峰值98%，连接池耗尽

  • swan_saga_local_branch_transaction表插入RT飙升至1.8s

  • 数据库主库因慢查询触发级联雪崩，sjstrmsodc4主库发生ORC切换失败，连接池耗尽。

  • 订单号生成服务与事务回滚逻辑共用集群，故障扩散至上游服务（odc.orderprocess、odc.menu等）。

  • 其他服务访问sjstrmsodc4开始出现获取连接超时

---

二、处理流程与关键操作

时间线

时间节点	关键操作	数据指标/效果
18:11	上游服务触发超时告警	接口超时率75%（持续15分钟）
18:12	DBA定位慢SQL（SQL ID:2171f2ab）	慢查询数1200+/分钟
18:15	启动跨团队协作（DBA/SRE/Swan）	参与团队：DBA 3人、SRE 2人、研发4人
18:23	dc4主库ORC切换失败	主从延迟峰值90秒
18:27	分阶段限流（50%→10%→0%）	QPS从5000降至200
18:29	PT-KILL清理慢查询	终止慢查询4500+条，CPU回落至40%
18:42	修复索引（新增idx_xid_branch）	查询耗时从1.8s降至5ms
18:43	放开限流，服务恢复	推单成功率恢复至99.9%

核心处置手段

1. 限流与熔断

   • 动态调整SQL流量，优先保护核心链路
   • 使用pt-kill终止慢查询，释放连接池资源

2. 索引修复

   • 修正联合索引顺序为(xid, branch_id)，消除全表扫描
   • 使用gh-ost工具执行在线DDL，主从同步延迟归零

3. 业务补偿

   • 人工补推**15%**异常订单（依赖商家手动处理）

---

三、根因分析

直接原因

分类	描述
索引设计缺陷	swan_saga_local_branch_transaction表索引顺序错误（idx_bid_xid），导致DELETE语句全表扫描
业务逻辑耦合	订单生成与事务回滚共享数据库集群，缺乏物理隔离

间接原因

分类	描述
巡检机制失效	全表扫描检测阈值过高（1000行），未覆盖高频低行数场景
预案缺失	无数据库故障降级工具，依赖人工补偿（耗时2小时以上）

---

四、改进措施与验证

技术优化

1. 索引治理

   • 建立联合索引顺序审核规则，覆盖**100%**高频操作表
   • 重建swan_saga系列表索引，查询性能提升90%

2. 熔断升级

   • 开发多维度限流工具（SQL ID + 服务标签），限流覆盖率提升至95%

架构解耦

措施	预期效果	进度
订单生成服务独立部署	降低跨服务影响80%	2022Q3落地
事务回滚表迁移	与核心业务物理隔离	已完成

监控增强

• 全链路追踪：部署慢SQL实时指纹分析，响应时间>50ms自动告警
• 动态阈值调整：全表扫描阈值降至500行，覆盖高频场景

---

五、系统性改进模型

改进维度	具体措施	预期收益
技术债务治理	索引顺序强制审核（Code Review）	减少**70%**索引缺陷引发的故障
容量韧性	核心集群QPS弹性扩容（基线×200%）	峰值承载能力提升至1.2万QPS
组织协同	DBA-研发-Swan联合巡检机制	高风险SQL漏检率下降85%
故障自愈	自动化补偿工具 + 无损降级策略	MTTR从32分钟缩短至8分钟

---

六、经验总结

技术视角

• 索引即资产：高频表需定期审计索引命中率，纳入发布流程卡点
• 容量兜底：核心服务预设弹性扩缩容策略，避免级联故障

管理视角

• 跨团队协作：建立常态化巡检机制，提前暴露耦合风险
• 预案演练：通过真实场景验证工具有效性（如限流覆盖率）

最终结论：通过索引治理、逻辑解耦与自动化工具建设，系统性降低数据库级联故障风险，保障订单核心链路SLA≥99.99%。