特性开关与数据迁移的隐性契约：一次 P99 从 80ms 飙到 2.4s 的 37 分钟复盘

作者沈寒山

特性开关灰度发布数据迁移MySQL事故复盘

结论先行：特性开关（feature flag）不是「代码开关」，它是一次隐性的执行计划变更。当你把 flag 从 0 切到 1 的那一刻，SQL 走的索引、JOIN 的表、缓存的 key 全变了——而这一层变化，绝大多数团队的变更流程完全没把它当回事。下面是一次真实复盘。

一、现象：QPS 没变，P99 却翻了 30 倍

先交代规模，方便后面判断量级：

服务：订单查询核心接口 /api/orders，单机 QPS 约 2000（3 个服务实例分摊）
数据库：MySQL 8.0.32，t_order 表 3.8 亿行、单表 210GB，InnoDB
正常水位：P50 28ms，P99 80ms，错误率 < 0.01%
事故窗口：周一下午 14:02 切 flag → 14:39 回滚，共 37 分钟

切完 flag 的 20 秒内，P99 从 80ms 直接拉到 2400ms，P50 也升到 410ms；同一时间 MySQL 的 Threads_running 从 12 飙到 96，Innodb_rows_read 速率翻了 40 倍。客服工单 8 分钟内涨了 2.3 万条，关键词全是「我的订单打不开」。

关键背景：这次上线做的事是把 t_order.price_v1（旧字段）迁移到 t_order.price_v2（新字段，含精度修正）。按团队惯例，代码里留了一个 flag order.price_v2.read，回填脚本跑完就切 flag。

二、根因：flag 提前切了 3 天，但真正炸的是执行计划

回滚后拉了 14:02 前后的慢日志和 EXPLAIN，根因拆成三层，从浅到深：

第 1 层（直接原因）：flag 切换前，回填只到 61%。 回填脚本的监控看的是「脚本是否存活」，不是「回填进度百分比」。DBA 同事当时以为脚本跑完了，实际上 3.8 亿行只回填了 2.32 亿行。剩下 1.48 亿行 price_v2 IS NULL。

第 2 层（放大器）：新代码路径多了一个 JOIN + 一次 filesort。 旧代码：SELECT ... WHERE user_id = ? ORDER BY created_at DESC LIMIT 20，走 (user_id, created_at) 复合索引，零 filesort。新代码因为要读 price_v2 并关联价格快照表 t_price_snapshot，SQL 变成了带 JOIN 的写法，执行计划从「索引范围扫描」退化成「hash join + filesort（temp table on disk）」。同一个接口，QPS 没变，单条 SQL 从 80ms 变 2400ms——30 倍的差距，不是数据量变化，是计划变化。

第 3 层（真正的隐性契约）：flag 切了 0→1，但「新字段 100% 非空 + 新索引就绪」这两个前提一个都没满足。 我们把 flag 当成了「代码开关」，但它实际是「执行计划开关 + 数据就绪开关 + 缓存契约开关」三合一。任何一条前提不满足，切了就是事故。

三、具体做法：把 flag 当成变更单来管

复盘后我们做了一套「flag 变更 SOP」，下面是可直接抄的模板。

1. flag 必须带「前置条件清单」，写进变更单

# flag: order.price_v2.read
# owner: 订单组 / @xxx
preconditions:
  - "t_order.price_v2 非空率 >= 99.9%（当前 61%，未达标）"
  - "索引 idx_user_created_price_v2 已存在且 EXPLAIN 无 filesort"
  - "影子对账 72h 差异率 < 0.001%（当前 0.02%，未达标）"
rollback:
  - "flag 0→1 切回 0 平均耗时 40s（含配置下发 + 缓存刷新）"
  - "回滚不依赖重新发布"

2. 影子对账：flag 切之前先「双读比对」72 小时

-- 影子查询：新路径跑一遍，只比对不返回
SELECT a.order_id, a.price_v2, b.price_final
FROM t_order a
JOIN t_price_snapshot b ON a.order_id = b.order_id
WHERE a.price_v2 IS NOT NULL
  AND ABS(a.price_v2 - b.price_final) > 0.01   -- 容差 1 分
LIMIT 1000;

采样 1% 流量、跑 72 小时，差异率 < 0.001% 才允许切。我们第一次跑差异率 0.02%，直接拦下了一次「切了才发现数据不对」的事故——这就是影子对账的价值：把 37 分钟的线上事故，变成 72 小时的离线比对。

3. 回填脚本必须上报「进度百分比」，而不是「是否存活」

# 回填：每批 2000 行，批间 sleep 200ms，限速 200 QPS
UPDATE t_order
SET price_v2 = price_v1 * 1.005,
    updated_at = NOW()
WHERE id BETWEEN :start AND :start + 1999
  AND price_v2 IS NULL;

监控指标改为 backfill_progress_pct（已回填行数 / 总行数），阈值 99.9% 才能放行 flag。进度没到，flag 平台的「允许切换」按钮直接置灰。

4. 缓存契约：flag 切换必须伴随缓存 key 版本化

旧 key：order:{order_id} 新 key：order:{order_id}:v2

绝不能复用同一个 key。这次事故里，切 flag 后 8 分钟内 Redis 里被写入了 200 万条脏缓存（用新逻辑查了未回填的行，结果 price_v2 = NULL 被序列化进去），回滚 flag 后还要手动 SCAN + DEL 清了 40 分钟。

四、踩过的坑与反直觉之处

「flag 回滚很快」是错觉。 我们确实 40 秒就切回了 flag，但那 37 分钟里产生的 2.3 万工单、200 万条脏缓存、被压垮的 DB 连接池，回滚一个 bit 位解决不了任何一条。回滚快 ≠ 损失小。
EXPLAIN 不骗人，但人会说谎。 事故后 DBA 说「我验证过执行计划没问题」——他验证的是「所有行都有 price_v2」的假设下的计划。一旦有 39% 的行是 NULL，优化器就换了路径。执行计划是「数据的函数」，不是「SQL 的函数」，数据分布一变，计划就变。
flag 平台只看「谁切的」，不看「切的前提」。 我们原来的 flag 平台只有一个「切 / 不切」按钮，没有前置条件校验。这次事故后最大的工程改动不是写代码，而是给 flag 平台加了 preconditions 字段和「不达标就置灰」的逻辑——把流程约束从「人肉自觉」变成「系统强制」。
「新代码路径」的复杂度被严重低估。 旧代码 1 张表、1 个索引；新代码 2 张表 JOIN + 1 个新索引 + 1 套新缓存。flag 切的那一下，变更面是 4 倍，但变更单上写的是「1 个 flag」。

五、结论与可复用清单

把这次事故浓缩成一份「flag 上线前检查清单」，建议贴到你们团队的 wiki 上：

[ ] flag 是否带 preconditions 清单，且每条都有可量化的达标条件？
[ ] 数据回填是否有「进度百分比」监控，而非「脚本存活」监控？
[ ] 新 SQL 路径是否在生产数据上跑过 EXPLAIN，且确认无 filesort / temp table？
[ ] 是否做了 ≥ 72 小时的影子对账，且差异率达标？
[ ] 缓存 key 是否版本化，避免新旧逻辑共用同一 key？
[ ] 回滚方案是否独立于「重新发布」，且实测过回滚耗时？
[ ] flag 切换时，DB 的 Threads_running、Innodb_rows_read 是否有实时告警阈值？

最后一句：

特性开关不是「安全网」，它是「第二份变更」。它切下去的那一刻，执行计划、数据分布、缓存契约、连接池水位全部变了——按变更单的流程来管它，才配叫「灰度」，否则只是「赌一把」。

赞 2 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。