结论先行：「走了索引」只说明第一跳（二级索引页）是热的，不说明第二跳（聚簇索引数据页）是热的。当二级索引小、聚簇索引大、buffer pool 装得下索引却装不下数据时，点查会稳定落在「索引命中 + 回表随机 I/O」的半命中区间——EXPLAIN 一切正常、整体命中率 97%+，但 P99 被数据页 miss 单独顶起来。这种查询不能用「加索引」三个字糊弄，必须把一次点查拆成两跳，分别算各自的 I/O 税，再决定覆盖索引 / 预热 / 接受成本。
一、现象：EXPLAIN 全绿，P99 就是 48ms
一套会员权益系统，主库 MySQL 8.0.32（16C64G，innodb_buffer_pool_size=48G），核心表 t_member_benefit：
- 6.2 亿行，聚簇索引（含全部列）约 145GB，二级索引
idx_member_status_expire (member_id, status, expire_at)约 3.8GB； - 该索引上 QPS ≈ 1200 的点查：
SELECT benefit_id, benefit_name, amount, ... 约 12 列 FROM t_member_benefit WHERE member_id=? AND status=1 AND expire_at>?，EXPLAIN：type=ref, key=idx_member_status_expire, rows≈15； - 监控：整体 buffer pool 命中率 97.4%，OS 层
%util长期 30~50%，await稳定 3~5ms； - 但业务侧 P50 = 1.2ms，P99 = 48ms，且 P99 不抖、是「平台」——不是冷读抖动的尖刺，而是每个请求都要付的那部分税。
第一反应加覆盖索引：没加（下面说原因），先拆账。
二、根因：一次点查是两跳，命中率是两跳的加权平均
InnoDB 的一次「二级索引点查」物理上是两段：
- 索引跳：定位
idx_member_status_expire的叶子页，取出 15 个主键值。索引 3.8GB < 48G buffer pool，且访问频率高，这一跳命中率 ≈ 99.9%，成本 ≈ 0； - 数据跳：拿 15 个主键回表，每行一次 B+ 树下降 + 一次页读取。15 个主键在 145GB 的聚簇索引里是随机分布的，这 15 个数据页大概率不在 buffer pool 里（145GB 装不进 48G，且这些是 3 个月前的老会员行，访问频率低）。
整体命中率 97.4% 正是这两跳的加权结果：索引跳几乎全命中，把数据跳约 20% 的 miss 稀释掉了。用整体命中率判断「这条查询快不快」，等于用班级平均分判断某个学生的数学成绩。
单行回表成本估算（NVMe，4K 随机读）：B+ 树 4 层下降约 4 次页访问 + 叶子页 1 次 ≈ 5 次页 IO；页 miss 时每次 3~5ms（本机 await 实测 3.8ms）。15 行 × 5 页 × 命中率补集，期望额外 I/O 成本落在 30~60ms 区间——与 P99 48ms 完全对得上。这不是「偶发慢」，是每次都要付、付多少取决于这 75 个页恰好 miss 几个的确定性成本。
参考陈星河那篇对 LRU young/old 机制的拆解（其核心观点是「命中不等于无代价」），这里补充一个他文里没展开的角度：数据页一旦 miss 被读进来，也大概率进 old list 尾部（新读页先进 old list 且需再次访问才晋升 young），对低频老行来说这页很快又被驱逐——预热了也留不住，这才是半命中查询「治标不治本」的机制根源。
三、具体做法：先拆账，再选药
3.1 量化确认是不是「半命中」（可复现）
-- 1) 看这条索引的叶子页实际大小（判断索引跳是否热）
SELECT table_name, index_name, stat_value
FROM mysql.innodb_index_stats
WHERE index_name = 'idx_member_status_expire' AND stat_name = 'size';
-- 返回页数，×16K 即索引物理大小；3.8GB ≈ 25 万页，远小于 pool
-- 2) 用 performance_schema 量「一次查询到底读了多少页」
UPDATE performance_schema.setup_instruments
SET enabled='YES', timed='YES' WHERE name='wait/io/file/table/io';
-- 或更直接：对目标 SQL 开 profiling
SET profiling=1;
SELECT ... WHERE member_id=123456 AND status=1 AND expire_at > NOW();
SHOW PROFILE IO FOR QUERY 1;
-- 关键行：读取 t_member_benefit.ibd 的 IO 次数与耗时
-- 实测：一次查询 68 次 file read，其中 63 次是数据页，总耗时 41.2ms
判定标准：索引跳 IO 耗时 < 1ms 且数据跳 IO 占总耗时 > 80% → 典型半命中。
3.2 三个药方与成本账
药方 A：覆盖索引（把第二跳消掉）
-- 把 SELECT 的 12 列里真正被读的 6 列并入索引
ALTER TABLE t_member_benefit
ADD INDEX idx_member_cover (member_id, status, expire_at, benefit_name, amount, start_date);
成本账必须算（这是我坚持先算再动的原因）：
- 这 6 列平均行宽 +84B，6.2 亿行 → 索引从 3.8GB 涨到约 56GB（二级索引叶子行 = 原索引键 17B + 主键 8B + 附加列，注意每行都付主键 8B 的重复存储）；
- 写入税：该表写入 QPS ≈ 4800，每个非唯一二级索引每次 INSERT/UPDATE 多一次 B+ 树随机写。56GB 索引已超出 buffer pool 的舒适区，change buffer 在 8.0 默认是关的（这点社区已有共识），合并写放大直接落盘——写 P99 预计从 2.1ms 涨到 6~9ms；
- 决策公式：读 QPS × 每次省下的 I/O 成本 vs 写 QPS × 每次多付的 I/O 成本 + 索引膨胀的内存税。本例 1200 × 45ms 省 vs 4800 × 5ms 多付，读收益占优 → 覆盖索引成立，但只挑 6 列覆盖，12 列全塞进去就是负收益（索引膨胀到 90GB+，写税和内存税反超）。
药方 B：定向预热（治标，适合批处理窗口）
对已知要扫的 member_id 批次，跑一遍 SELECT ... LIMIT 1 把数据页读进 pool。注意 3.2 节说的 old list 机制：预热只对「预热后 30 分钟内还会再查同一批」的场景有效，一次性冷数据预热是白烧 I/O。
药方 C：接受成本，改架构（本例最终选择）
把 12 列里 6 个低频展示列（benefit_name 等）拆到 t_member_benefit_detail，点查只碰 6 列主表 + 1 次 PK join。拆完后：
- 主表聚簇索引 145GB → 98GB，热行密度提升 32%；
- 点查 P99：48ms → 6.3ms（剩余成本是主键 join 那一跳，detail 表按 member_id 分桶后基本命中）；
- 写路径不变，零写税。
落地成本：双写过渡 2 周 + 数据回刷 11 小时（pt-online-schema-change 在线执行，锁等待峰值 40ms）。这是三个药方里唯一把「数据页 miss」的根因（表太宽、热数据密度太低）真正消掉的。
四、踩过的坑（反直觉清单）
- 整体命中率 97.4% 是最强的误导：它把索引跳的全命中和数据跳的 20% miss 混在一个数里，监控看板上「一切正常」和 P99 48ms 并存了 3 周没人发现。拆账必须拆到「索引跳 / 数据跳」两级；
- 预热是安慰剂：对低频老行做全表预热，页进 old list 后 20~40 分钟被驱逐，第二天的 P99 一点没降，还烧了 18GB 读 I/O。预热只对「预热-复用间隔 < 驱逐窗口」的批处理有效；
- 覆盖索引不是越多列越好：我们最初把 12 列全塞进去，压测发现写 P99 从 2.1ms 涨到 14ms、索引 91GB，回滚后只留 6 列，写 P99 回到 6.8ms。覆盖列数量要按「读省下的 I/O − 写多付的 I/O − 内存税 > 0」反推上限；
- 8.0 上别指望 change buffer 兜底写放大：8.0.3 起
innodb_change_buffering默认 none，覆盖索引带来的写放大是实打实的随机落盘，算成本账时不能按 5.7 的直觉打折扣。
五、结论与可复用清单
判定：EXPLAIN 正常（type=ref、rows 小）但 P99 稳定偏高、且 SHOW PROFILE IO 显示 IO 耗时集中在数据页 → 半命中查询，不是索引问题。
决策顺序（按成本从低到高）：
- 算
数据页 miss 期望成本 = 回表行数 × B+树深度 × miss 率 × 单次随机读耗时，与 P99 对不上再怀疑锁等待 / 其他因素； - 读 >> 写且覆盖列少 → 覆盖索引，列数用成本公式反推上限；
- 读 < 写或表太宽 → 拆窄表（治本，唯一消根因的方案）；
- 预热只给「预热-复用间隔短」的批处理用，日常点查预热 = 烧 I/O。
三个关键数字（本例）：索引 3.8GB 全热 vs 数据 145GB 装不进 48G pool；15 行回表 ≈ 75 个页的随机读决定 P99 48ms；拆窄表后 P99 48ms → 6.3ms，写路径零代价。
一句话：「走了索引」是及格线，不是达标线；达标线是「两跳都热，或者第二跳不存在」。