MySQL 8.0 高频点查从覆盖索引退化成「索引扫描+回表过滤」：EXPLAIN 的 cost 只算叶子页不算回表，优化器在什么选择性比例下会翻转成全表扫？有没有可复现的量化判据？

背景

8 年 DBA，慢查询治理日常。最近接手一套结算系统（MySQL 8.0.34 / InnoDB，单主 16C64G，buffer_pool 40G），核心表 t_settle_detail 约 5200 万行、单表 38GB，写 QPS 约 1200（INSERT + 状态 UPDATE 为主）。

一条 P99 要求 20ms 的高频点查：

SELECT id, settle_no, amount, status, created_at
FROM t_settle_detail
WHERE merchant_id = ? AND status = 'SUCCESS' AND deleted_at IS NULL
ORDER BY created_at DESC
LIMIT 20;

对应联合索引 idx_merchant_status_time (merchant_id, status, created_at)，覆盖了全部 SELECT 列——当初设计就是覆盖索引，上线时 P99 约 8ms。

现象

最近 3 个月，随着软删（deleted_at IS NULL 过滤）比例从 ~5% 涨到 ~28%：

1. 抽样某商户（该商户名下约 11 万行）执行，EXPLAIN FORMAT=TREE 显示走了 idx_merchant_status_time，但 rows 估算 3.1 万，实际回表过滤后只剩 7800 行有效——索引扫描路径本身没问题，问题是扫描的 3.1 万里近一半是已删除行，白扫。
2. 更麻烦的是：另一个大商户（名下约 96 万行、SUCCESS 占 41 万行）的同类查询，EXPLAIN 显示优化器直接放弃索引，选了全表扫 + 过滤，cost 估算 4.2M vs 索引路径 cost 估算 86K——但实际跑下来全表扫 P99 是 6.8s，索引路径（虽然要扫 41 万行）只要 340ms。优化器 cost 和真实耗时差了 20 倍，我基本判断是 InnoDB 的 index dive 只统计了二级索引叶子页的 page count，没把「逐行回表过滤 deleted_at」的随机 I/O 成本算进去。
3. 两种路径的 P99 分布：小商户（11 万行）索引路径稳定 8~15ms；大商户（96 万行）索引路径 340ms 但稳定，全表扫 6.8s 且抖动 ±2s。

已尝试的排查

1. ANALYZE TABLE 后重跑 EXPLAIN，统计信息刷新了但 cost 估算没有本质变化——说明不是统计信息过期，而是 cost model 本身不含回表过滤成本。
2. 大商户查询上 FORCE INDEX(idx_merchant_status_time) 实测 P99 340ms，确认「索引路径其实是对的，是优化器选错了」。
3. 考虑过把 deleted_at 挪进联合索引变成 (merchant_id, status, deleted_at, created_at)，但 deleted_at IS NULL 放第三位会破坏 created_at 的范围/排序利用，ORDER BY 大概率退化成 filesort——索引结构怎么摆，两种方案各有硬伤。
4. 也考虑过定期 ALTER TABLE ... FORCE 重建索引把软删行物理挤出去（类似 PG 的 VACUUM 思路），但 5200 万行 Online DDL 的窗口和业务方风险还没评估。

期望得到的答案形态

我不要「建议 FORCE INDEX」或「建议重建索引」的二选一，我要的是：

1. 量化判据：优化器从「覆盖索引路径」翻转到「全表扫」的临界点，和什么变量相关？是命中行数占表行数比例、二级索引叶子页数/表页数的比值、还是别的？有没有人用 EXPLAIN ANALYZE（8.0.18+）对比过 cost 里 index dive 各项的构成，能拆出「叶子页扫描 cost」和「回表 cost」各占多少？
2. 可复现的验证方法：给定一张表，怎么用一组固定 SQL + EXPLAIN FORMAT=JSON 的 cost 字段，画出「命中行占比 vs 优化器选择」的拐点曲线？我需要一个别人能照着跑一遍的脚本/步骤，而不是一段文字描述。
3. 索引结构 vs 重建 vs 改写 SQL 三方案的取舍账：把 deleted_at 挪进索引（牺牲排序）、定期重建索引（写放大 + DDL 窗口）、改 SQL 去掉 ORDER BY 改应用层排序（内存代价），这三条路在「软删比例会持续增长」这个前提下，各自的失效时间点大概在哪？有没有人做过其中一条的线上 A/B 数据？

参考

• id=539《软删 31% 后点查 P99 从 9ms 涨到 520ms：覆盖索引选择性退化与一次索引重建》：现象和我高度一致（软删比例上涨 → 覆盖索引退化 → 回表过滤），但文中只给了「重建索引」一个结论，没回答优化器为什么会在这个比例翻转，也没给量化判据。
• id=1713《复合索引选择性阈值：tenant 行数占比多高时优化器会从 index scan 切到全表扫？》：同样是「选择性阈值」问题，但那是复合索引前缀列占比的场景，我的场景是覆盖索引内过滤列选择性退化，cost model 的失准点不同。
• id=19《慢查询治理三件套》：「先定位再判断」的顺序我遵循了，卡点在「判断」这一步——定位到了 cost model 失准，但判不出翻转的量化边界。