结论先行：索引没变、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 都更新，而是：
- 表首次被访问 / 执行
ANALYZE TABLE时采样； - 之后当表内行数相对上次统计发生显著变化（默认阈值
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 分钟就告警——这能在用户感知前抓到统计信息漂移。
四、踩过的坑 / 反直觉之处
- 「buffer pool 命中率 99% 也照样慢」是反直觉的。 命中率只说明数据在内存里，不说明回表行数对不对。这次事故命中率没掉，但回表行数从 6 万涨到 110 万，慢的全是「多读了 104 万行」。
ANALYZE TABLE是「按表」触发，但选择性估算是「按列前缀」的。 表级行数统计更新 ≠ 你关心的biz_date+channel前缀基数被更新了。这是最容易误判的地方：你会以为「行数变了统计就该重算了」，但维度选择性是另一回事。LOAD DATA批量补数是最危险的写入方式之一。 它一次性改变基数分布，且因为是「历史异构数据」，会让优化器对「在线维度」的估算彻底跑偏。补数最好分批次、带channel分布与线上一致的样本，或补完立刻ANALYZE TABLE。innodb_stats_persistent_sample_pages默认 200 对 4 亿行大表偏小。 基数估算本身就有采样误差，倾斜列上会放大。对核心大表调到 500~1000 更稳（代价是ANALYZE更慢一点）。- 别把 FORCE INDEX 当永久方案。 它是「人肉优化器」，数据一变就变成新的坑。
五、结论与可复用清单
核心结论：执行计划漂移的第一嫌疑人，往往不是「没索引」，而是「统计信息过期 + 维度选择性失真」。它的特征是不报错、不锁表、只让 rows 估算骗你，排查时要先对拍「估算 vs 真实行数」。
可复用清单（按成本从低到高）：
- 止血（秒级）：
EXPLAIN FORMAT=JSON对拍 rows 估算与真实，确认偏差倍数；偏差大 →ANALYZE TABLE。 - 根治（分钟级）：倾斜低基数列加直方图
... UPDATE HISTOGRAM col WITH 64 BUCKETS；大表把innodb_stats_persistent_sample_pages调到 500~1000。 - 护栏（持续）：对 P99 敏感查询短期
FORCE INDEX止血，稳定后摘除；把「估算/真实行数比 > 3」做成持续告警。 - 流程（预防）：批量补数 / 大迁移完成后必须执行
ANALYZE TABLE并复核核心查询的 EXPLAIN；补数样本尽量贴近在线维度分布。
一句话记忆：索引是「路」，统计信息是「导航」；路没问题，导航给错路，照样把你带到最远的那条路上。