MySQL 8.0 分区表分区键选择性退化：2.8 亿行按 tenant_id HASH 分区，大租户(占 12%)点查优化器放弃复合索引走全分区扫描，FORCE INDEX 是止血还是该拆冷热表？临界判据怎么定？

背景 MySQL 8.0.32（RDS，32C128G，buffer_pool 96G），交易流水表 t_txn 约 2.8 亿行，按 tenant_id 做 HASH 分区（64 个分区），二级索引 idx_tenant_bizdate_status (tenant_id, biz_date, status)。查询模式（90%+ 流量）：tenant_id = ? AND biz_date BETWEEN ? AND ? AND status = ?，带 LIMIT 200。租户分布严重长尾：Top 5 租户合计占 34%，其中最大的 T001 单租户 3360 万行（12%）。

现象

• T001 的查询：EXPLAIN 显示 type=index, rows≈4200万，走了 idx 但 P99 稳定 850ms–1.2s（本质是全索引扫，因为 biz_date 范围 90 天覆盖了该租户 87% 的数据）；
• 小租户（<50 万行）：同一条 SQL P99 3–8ms，rows 估算精确；
• 我试过 FORCE INDEX(idx_tenant_bizdate_status)：没有用，因为优化器本来就没放弃这个索引——问题是索引内 rows 太大，index scan 代价 > 优化器估算的全表/全分区代价，它选了 type=ALL（rows≈44万/分区，64 分区并行扫），P99 反而 1.8s；
• innodb_stats_persistent=ON，ANALYZE TABLE 后计划不变；optimizer_trace 显示 cost 对比是 index scan 210 万 vs table scan 180 万，210 vs 180 这种贴脸差距让我怀疑是成本模型对大分区估算的精度问题。

已尝试

1. FORCE INDEX —— 无效（如上，索引本来就在候选里，是代价输了）；
2. 调 eq_range_index_dive_limit —— 该 SQL 不是 range dive 场景，无效；
3. 把 biz_date 范围从 90 天缩到 30 天（业务侧改前端默认值）—— T001 P99 降到 95ms，但业务不接受「默认只能看 1 个月」；
4. 考虑过按 biz_date RANGE 月分区替代 tenant HASH —— 但 95% 查询仍带 tenant_id，跨分区裁剪会退化，且 2.8 亿行在线迁移风险高。

想问的（期望答案形态）

1. 临界判据：分区键选择性退化到什么程度（单租户占比 X% + 索引内匹配行数 Y），MySQL 8.0 优化器会稳定地从 index scan 切到 table scan？有没有人用 optimizer_trace 量化过这个 cost 分界？
2. 拆冷热表的真实取舍：把 T001 这类 Top 5 租户拆到独立表（或独立实例），读路径按租户路由 —— 你们线上做过吗？写入侧双写/路由的复杂度、DDL 双份维护、未来新大租户出现时的迁移成本，值不值？
3. 中间方案：有没有比「拆表」轻、比「FORCE INDEX」稳的手段？比如：按 biz_date 做二级 RANGE 分区（两级分区）、ProxySQL 层对 Top 租户路由到只读从库 + 预聚合表、或者 MySQL 8.0.36 的 index dive 改进是否对这种「分区键高选择 + 索引内大范围」场景有实质改善？
4. 成本模型校准：optimizer_cost_model 的 memory_typed / io_block_read_cost 调参有没有人真在生产上用它翻转过 index vs table scan 的选择？风险多大？

引用依据：站内 [id=1575] 讨论过「分区裁剪正确但 rows 估算按全表算」，我的场景方向相反（裁剪正确但裁剪后单分区内部选择性退化）；[id=1713] 讨论过「复合索引选择性阈值」，但那是非分区表。两者交叉的场景（分区键本身就是低选择性列）我没找到现成答案。