MySQL 8.0 二级索引本可免排序，优化器却选全表扫描+filesort：max_seeks_for_key 的取舍有没有可复现的判断方法？

背景

MySQL 8.0.32 / InnoDB，单主 32C/128G，innodb_buffer_pool_size=64G。核心表 t_msg_log 约 1.2 亿行，PK=id，二级索引 idx_user_ts (user_id, created_at)，其中 user_id 高基数（单值 300～2 万行不等），created_at 是 DATETIME。

高频查询：

SELECT id, user_id, created_at
FROM t_msg_log
WHERE user_id = ? AND created_at BETWEEN ? AND ?
ORDER BY created_at DESC
LIMIT 20;

现象

对 user_id 命中 2000～20000 行、时间窗 7 天的查询，EXPLAIN 稳定显示 type=ref, key=idx_user_ts, Extra=Using index; Using filesort——走索引扫描后还要 filesort。但把 WHERE 里的时间窗放宽（命中行数从 1 万涨到 5 万），优化器反而切回 type=index, key=idx_user_ts, Extra=Using index（直接索引序扫描 + LIMIT 提前终止）。也就是说：命中行数越多，反而不需要 filesort；命中行数适中的中间态，优化器偏偏选了更贵的路径。我怀疑是 max_seeks_for_key 的代价模型在这个区间把「索引扫 + filesort」估成了更便宜的一条，但无法证实。

已尝试

1. SET optimizer_trace_max_mem_size 打开 trace 对比两条路径的 rows_examined_per_range / cost，trace 里能看到优化器把 ref 路径的 cost 估成约 1.8 万，index 路径约 4.2 万——但 cost 数字与实际执行耗时对不上（实测 ref+filesort 反而比 index 慢 3～5 倍）。
2. SET max_seeks_for_key=1 强制走 ref：确实切回 ref+filesort，但 P99 更差，确认这条路径在这个行数区间就是错的。
3. 把 sort_buffer_size 从 256K 调到 4M，filesort 没落盘（tmp_disk_tables 没涨），但 CPU 排序本身仍是主要开销。
4. 试过 IGNORE INDEX(idx_user_ts)，强制全表扫描，慢到不可用，排除。
5. 加覆盖索引 idx_user_ts_id (user_id, created_at, id)：filesort 仍在，只是回表消失，P99 只降 20%。

期望得到的答案形态

1. 决策依据：MySQL 8.0 里「ref 扫 + filesort」vs「index 全序扫 + LIMIT 提前终止」的代价模型，关键变量到底是哪几个（max_seeks_for_key、range_optimizer_max_mem_size、max_length_for_sort_data 哪个在这条路径上生效）？有没有可复现的最小复现 SQL 能让我自己验证？
2. 可操作判据：给定 (命中行数, LIMIT, 索引选择性、排序列基数)，能不能给一个阈值公式或决策表，判断该走哪条路径？还是说这个区间就该用 FORCE INDEX 兜底？
3. 兜底方案：如果优化器在这个区间必然选错，除了 FORCE INDEX，有没有更稳的写法（比如改索引列序、拆成两个查询用 UNION、用游标分页）？各自的边界条件是什么？

参考：站内已有人问过 (a,b) 联合索引 + WHERE a IN + ORDER BY b 触发 filesort（id=187），以及 filesort 落盘的排查（id=41），但都没覆盖「命中行数中等区间、优化器代价模型选错路径」这个具体场景。