同一索引同一 SQL，凌晨 P99 从 15ms 飙到 3.4s：统计信息漂移的根因与修复

结论先行：索引没变、SQL 没变、buffer pool 命中率也没掉，但 P99 还是从 15ms 飙到了 3.4s——根因是 InnoDB 的统计信息（cardinality）在数据批量写入后严重失真，优化器据此选错了索引/访问路径。这类「执行计划漂移」的坑，比绝大多数「索引没建好」更隐蔽，因为它不报错、不锁表，只在 EXPLAIN 的 rows 估算里悄悄骗你。下面用一个真实案例讲清机制与修复。

一、现象与背景：什么都没改，查询就是慢了

场景：一套风控决策引擎的 t_event 表，MySQL 8.0.32、InnoDB、单表约 4.2 亿行、表大小 118GB，按 event_time 做 RANGE 分区（28 个分区）。核心查询是一条按业务日聚合的窗口读取：

SELECT event_id, user_id, risk_score
FROM t_event
WHERE biz_date = '2024-11-02'
  AND channel = 'h5';

这条查询平时 P99 稳定在 12~18ms，走的是联合索引 idx_biz_channel(biz_date, channel, event_id)，一次 range scan 命中约 6 万行。

某天凌晨 3 点，监控告警：同一查询 P99 飙到 3.4s，QPS 没变（约 320/s），CPU 反而下降（因为查询在等 IO 和回表）。业务侧表现为风控接口超时熔断。诡异的是：

• SHOW ENGINE INNODB STATUS 里 buffer pool 命中率仍是 99.2%；
• 没有锁等待（information_schema.innodb_trx 干净）；
• 索引、表结构、SQL 文本、sql_mode 在事故前后零变更（有变更审计背书）；
• 唯一的外部动作：凌晨 2 点跑了一次 T+1 的批量补数，往 t_event 灌了约 1.8 亿行历史回溯数据。

二、原理与根因：优化器只信「估算行数」，而估算信了过期的统计信息

先讲机制，再对号入座。

InnoDB 优化器选访问路径时，依赖的是 information_schema.statistics 里的 CARDINALITY（基数）和 LEAF_PAGES（叶子页数），而不是真实行数。InnoDB 默认走 innodb_stats_persistent（8.0 起默认开启），统计信息不是每次 DML 都更新，而是：

1. 表首次被访问 / 执行 ANALYZE TABLE 时采样；
2. 之后当表内行数相对上次统计发生显著变化（默认阈值 innodb_stats_auto_recalc=ON，触发条件是「自上次统计后累计变更的行数 > 基数的 10%」）才自动重算。

问题就出在这里。我们的补数一次性灌了 1.8 亿行，但补数走的是 LOAD DATA / 批量 INSERT 且集中在少数几个分区。InnoDB 的自动重算是按表触发的，而我们的查询是按分区 + 按 channel 维度做选择性判断的。结果：

• 表的总行数统计被更新（总基数上去了），但联合索引 idx_biz_channel 上 channel='h5' 这个前缀的基数估算，因为新灌入的数据 channel 分布与在线流量差异极大（回溯数据里 h5 占比只有 1.7%，而在线是 11%），优化器据此低估了 channel='h5' 的选择性；
• 于是 EXPLAIN 的 rows 估算从真实的 6 万被算成约 40 万，优化器认为「range scan 回表 40 万行太贵」，改选了按 biz_date 单列索引 idx_biz_date 做 range，再回表 + 内存过滤 channel——回表量从 6 万变成 110 万，P99 自然崩到秒级。

一句话根因：统计信息是「采样 + 滞后」的，而批量异构写入让它对「维度选择性」的估算彻底失真，优化器做了全局看似合理、局部却灾难的路径选择。

三、具体做法：先验证，再修统计，最后加「护栏」

1. 用 EXPLAIN 对拍，锁定「估算行数 vs 真实行数」的偏差

EXPLAIN FORMAT=JSON
SELECT event_id, user_id, risk_score
FROM t_event WHERE biz_date='2024-11-02' AND channel='h5';

对比 rows_examined（真实，加 SHOW PROFILE 或 performance_schema 取）与 rows（估算）。事故时 rows 估算 40 万、真实 6 万，估算/真实 ≈ 6.7x，这就是漂移的铁证。

2. 重算统计信息（成本极低，先做）

ANALYZE TABLE t_event;
-- 8.0 可指定采样精度，默认 200，热点表可调到 1000 提高基数精度
SET GLOBAL innodb_stats_persistent_sample_pages = 1000;
ANALYZE TABLE t_event;

成本与收益权衡：ANALYZE TABLE 对 4.2 亿行大表约耗时 9~14s，期间不锁 DML（只短暂持 MDL 元数据锁），凌晨低峰执行风险可控。重算后 EXPLAIN 立刻回到 idx_biz_channel，P99 恢复 15ms。这一步通常就能止血。

3. 用直方图补「维度选择性」这块短板（针对 channel 这类低基数但倾斜的列）

如果重算后仍偶发漂移，给倾斜列建直方图：

ANALYZE TABLE t_event UPDATE HISTOGRAM channel WITH 64 BUCKETS;
SELECT JSON_EXTRACT(histogram, '$.buckets') FROM information_schema.column_statistics
WHERE table_name='t_event' AND column_name='channel';

直方图让优化器对 channel='h5' 的选择性估算从「均匀分布假设」变成「按桶真实分布」，对倾斜数据收益明显。

4. 加「护栏」：别让优化器自由发挥

对这类对 P99 敏感的固定查询，用 hint 或改写锁定路径，把「优化器选路」从运行时变量里拿掉：

-- 方案 A：强制走目标索引（简单直接，适合固定查询）
SELECT ... FROM t_event FORCE INDEX (idx_biz_channel)
WHERE biz_date='2024-11-02' AND channel='h5';

-- 方案 B（更推荐）：让覆盖索引直接出 event_id，把回表量压到 0
-- 确认 idx_biz_channel 已含 event_id 后，回表本就该很少；
-- 真正该做的是把高频列 user_id/risk_score 也收进覆盖索引，或改走汇总表

落地成本权衡：FORCE INDEX 是最快的止血，但它把优化器的判断权收走了——一旦未来数据分布真的变了，你会失去自动纠偏能力，需要人来维护。所以我的做法是：止血用 FORCE INDEX，根治靠「重算 + 直方图 + 监控」三件套，观察 1~2 周稳定后再摘掉 FORCE INDEX。

5. 监控护栏：把「估算行数/真实行数比」做成告警

在 performance_schema 或慢日志分析里，对核心查询持续计算 estimated/actual 比值，比值 > 3 且持续 5 分钟就告警——这能在用户感知前抓到统计信息漂移。

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

1. 「buffer pool 命中率 99% 也照样慢」是反直觉的。 命中率只说明数据在内存里，不说明回表行数对不对。这次事故命中率没掉，但回表行数从 6 万涨到 110 万，慢的全是「多读了 104 万行」。
2. ANALYZE TABLE 是「按表」触发，但选择性估算是「按列前缀」的。 表级行数统计更新 ≠ 你关心的 biz_date+channel 前缀基数被更新了。这是最容易误判的地方：你会以为「行数变了统计就该重算了」，但维度选择性是另一回事。
3. LOAD DATA 批量补数是最危险的写入方式之一。 它一次性改变基数分布，且因为是「历史异构数据」，会让优化器对「在线维度」的估算彻底跑偏。补数最好分批次、带 channel 分布与线上一致的样本，或补完立刻 ANALYZE TABLE。
4. innodb_stats_persistent_sample_pages 默认 200 对 4 亿行大表偏小。 基数估算本身就有采样误差，倾斜列上会放大。对核心大表调到 500~1000 更稳（代价是 ANALYZE 更慢一点）。
5. 别把 FORCE INDEX 当永久方案。 它是「人肉优化器」，数据一变就变成新的坑。

五、结论与可复用清单

核心结论：执行计划漂移的第一嫌疑人，往往不是「没索引」，而是「统计信息过期 + 维度选择性失真」。它的特征是不报错、不锁表、只让 rows 估算骗你，排查时要先对拍「估算 vs 真实行数」。

可复用清单（按成本从低到高）：

1. 止血（秒级）：EXPLAIN FORMAT=JSON 对拍 rows 估算与真实，确认偏差倍数；偏差大 → ANALYZE TABLE。
2. 根治（分钟级）：倾斜低基数列加直方图 ... UPDATE HISTOGRAM col WITH 64 BUCKETS；大表把 innodb_stats_persistent_sample_pages 调到 500~1000。
3. 护栏（持续）：对 P99 敏感查询短期 FORCE INDEX 止血，稳定后摘除；把「估算/真实行数比 > 3」做成持续告警。
4. 流程（预防）：批量补数 / 大迁移完成后必须执行 ANALYZE TABLE 并复核核心查询的 EXPLAIN；补数样本尽量贴近在线维度分布。

一句话记忆：索引是「路」，统计信息是「导航」；路没问题，导航给错路，照样把你带到最远的那条路上。