复合索引选择性阈值：tenant 行数占比多高时优化器会从 index scan 切到全表扫？有没有可量化的判据或稳定压住计划的手段？

背景

我负责一套 SaaS 多租户订单库，MySQL 8.0.36（InnoDB，16C64G，buffer_pool 48G），核心表 t_order 约 1.2 亿行，联合索引 idx_tenant_time (tenant_id, created_at)。业务上 95% 的查询都带 tenant_id，按「大多数查询带它」的假设建了这个索引。

现象

最近 3 个月租户从 200 涨到 800，其中 3 个头部租户合计占全表约 47% 的行。同一 SQL：

SELECT id, amount, status FROM t_order
WHERE tenant_id = ? AND created_at >= ? ORDER BY created_at DESC LIMIT 20;

• 小租户（<1% 占比）：走 idx_tenant_time，P99 约 3ms；
• 头部租户（单 tenant 占 15%+）：EXPLAIN 直接切到 type=ALL 全表扫，P99 飙到 2.8s；
• 同一个租户，白天低峰走索引、晚高峰又切回全表扫（怀疑统计信息刷新时机影响，但还没验证）。

已尝试

1. 把 idx_tenant_time 改成覆盖索引 idx_tenant_time_cover (tenant_id, created_at, id, amount, status)，头部租户仍然全表扫——说明不是回表成本的问题；
2. ANALYZE TABLE 后立即查，头部租户依然 ALL；小租户正常；
3. 用 FORCE INDEX (idx_tenant_time) 压住计划，头部租户 P99 从 2.8s 降到 180ms——说明索引本身是可用的，纯粹是优化器 cost 判断偏了；
4. 建了 information_schema 上的 histogram（ANALYZE TABLE ... UPDATE HISTOGRAM），计划暂时稳定，但 24h 后批跑写入大量数据后又漂移回 ALL。

期望的答案形态

1. 可量化的判据：tenant 行数占比（或 cardinality(tenant_id) 与总行数的比值）到什么阈值附近，优化器会倾向切全表扫？有没有从 information_schema.INDEX_STATISTICS / mysql.innodb_index_stats 直接算出这个临界值的方法？
2. 稳定压住计划的手段：FORCE INDEX 硬编码 vs 应用层按 tenant 路由不同 SQL vs 分区表按 tenant_id 分，哪种在 800 个租户、3 个头部占 47% 的场景下运维成本最低？
3. 统计信息漂移的治理：histogram 24h 后失效，有没有比「定时 ANALYZE」更轻量的方案（比如按写入量触发、或 per-tenant 统计）？

参考

站内已有几篇讨论租户分布与索引取舍的文章，但都偏向「列序怎么选」和「覆盖索引值不值」，没覆盖「同一索引对不同租户走不同计划」这个动态漂移问题：

• 《加了索引还是慢：索引选择性、覆盖索引与回表成本的一次量化拆解》
• 《复合索引首列选择性退化：8800 万行工单表 status 只有 3 个值，大租户点查优化器偏全表扫》