索引明明命中但同一条 SQL 偶发慢 50 倍：P99 抖动的根因怎么定位

【背景】 我在一个订单中心做慢查询治理，主库 MySQL 8.0.32（单主 16C64G，innodb_buffer_pool_size=48G），核心表 orders 约 2.2 亿行，二级索引 idx_uid_created (uid, created_at)。业务方反馈"同一个用户偶尔刷不出订单"，我拉了一段监控看 P99：同一条 SQL 在大部分时间 3-8ms，但每 5-15 分钟会有一小撮请求飙到 300ms-1.5s，P99 长期在 400ms+ 徘徊。

【现象】

• SQL 形如 SELECT ... FROM orders WHERE uid = ? ORDER BY created_at DESC LIMIT 20；
• EXPLAIN 稳定显示 type=range / key=idx_uid_created，rows 估计 120-400，Extra=Using index condition；
• 慢日志（long_query_time=0.2）抓到的慢样本里，实际执行计划与 EXPLAIN 一致，没有出现 filesort，也没有临时表；
• 监控侧同一时刻 buffer pool 命中率 99.6%，无长事务、无锁等待（information_schema.innodb_trx / performance_schema.data_lock_waits 都为空）；
• 抖动是"尖刺"型，不是"整体抬升"，重启实例后短期内消失，几小时后又复现。

【已尝试的排查】

1. 关掉 query cache（8.0 已无）和一般性参数（innodb_flush_method 等）——无效；
2. 用 pt-query-digest 对慢日志做聚合，发现慢样本的 query 文本完全一致，只是执行时间差几十倍；
3. 怀疑是索引页冷读，但 buffer pool 命中率和 free list 都正常，且抖动前 1s 同 uid 的请求都是快的；
4. 怀疑是行级锁，但 data_lock_waits 里没有对应等待；
5. 怀疑是优化器在某个参数（比如 eq_range_index_dive_limit、optimizer_switch）下偶发换计划，但 EXPLAIN FORMAT=TREE 抓到的慢样本执行计划与快样本完全一样。

【我目前的两个猜测，想请大家帮我判断】 A. InnoDB 二级索引页在 buffer pool 里的 LRU 驱逐 + 重新读取（但 buffer pool 命中率高，这个解释有点矛盾）； B. 同一 uid 下订单量分布不均（少数"大 uid"订单量 5w+），当 ORDER BY 需要回表排序的代价被低估时偶发触发 filesort——但 EXPLAIN 里没有看到 Using filesort，这条我也没完全排除。

【期望得到的答案形态】

1. 一条可复现的诊断路径：从"快慢样本对比"入手，应该先看哪几张表 / 哪几个性能指标（performance_schema 的具体表名和字段最好）；
2. 针对"索引命中但偶发慢"这种场景，你实际踩过的坑和最终解法（参数 / SQL 改写 / 索引调整 / 架构层面）；
3. 如果是我上面两个猜测里的某一个，请告诉我怎么进一步验证；如果是别的方向，请直接给方向。

参考：站内已有《加了索引还是慢：索引选择性、覆盖索引与回表成本的一次量化拆解》（id=732）讲过覆盖索引与回表，但我的场景是"索引命中且 EXPLAIN 稳定"，和那篇讨论的"索引选择性差"不完全重合，所以单独问一次。