复合索引首列选择性退化：8800 万行工单表 status 只有 3 个值，大租户点查优化器偏全表扫，拆索引还是别的方案？

背景

SaaS 工单系统，主库 MySQL 8.0.32（InnoDB，32C128G，innodb_buffer_pool_size=96G，NVMe 本地盘），核心表 t_ticket：

• 规模：8800 万行、单表 112GB
• 字段：id（bigint 自增 PK）、tenant_id（bigint）、status（tinyint，3 个枚举：1=待处理 / 2=处理中 / 3=已解决）、title（varchar(256)）、created_at（datetime）、updated_at
• 写入压力：INSERT + UPDATE 合计约 4000 TPS
• 现有二级索引：idx_status_tenant_time (status, tenant_id, created_at DESC)
• 高频查询（客服后台列表页）：

SELECT id, title, created_at
FROM t_ticket
WHERE status = 1 AND tenant_id = 8821
ORDER BY created_at DESC
LIMIT 50;

现象

• 中小租户（status=1 下该 tenant 命中 < 5000 行）：走 idx_status_tenant_time，P99 约 8ms，正常；
• 大租户（status=1 下命中 230 万行，头部 3 个租户占 status=1 总量的 41%）：优化器估算 rows≈2300000，偏 全表扫描 + filesort，P99 12.4s，业务方天天报障；
• ANALYZE TABLE t_ticket 后重跑，估算还是 230 万，决策不变；
• FORCE INDEX(idx_status_tenant_time) 对比：大租户 P99 6.8s（比全表扫还慢——因为索引段内 status=1 有 2960 万行，按 tenant_id 定位到 8821 的段仍要扫过前面 ~2700 万个非本租户条目，逐行回表取 title）；
• FORCE INDEX(PRIMARY) 全表扫基线：P99 2.4s（buffer pool 命中率 82%，顺序读占优）。

已尝试与结果

1. ANALYZE TABLE 刷新统计信息 + 重跑 → 优化器决策不变，仍然全表扫；
2. FORCE INDEX(idx_status_tenant_time) vs FORCE INDEX(PRIMARY) 对比 → 大租户走索引 6.8s > 全表扫 2.4s，索引路径反而更差；
3. 把 title 加进索引做覆盖索引 → 索引从 1.8GB 涨到 4.1GB，status=1 段膨胀后大租户走索引 P99 只降到 6.1s，没质变，已回滚；
4. 查了热榜上一个相关的统计信息刷新提问（见引用），但那个问的是「刷新时机」，我这里是「刷新了也没用、估算对但代价模型仍然选全表扫」。

卡点与期望

我现在的纠结是：

• 方案 A：拆索引——把 idx_status_tenant_time 删掉，改成 idx_open (status, tenant_id, created_at) 只保留 status=1 的段（用生成列或分区过滤），或干脆按 status 拆 3 张表/3 个索引。8800 万行 + 4000 TPS 下多维护一棵 B+ 树的写放大到底多少？status 只有 3 个值，拆出来的索引选择性会不会还是差？
• 方案 B：分区——按 tenant_id 或 status 做 RANGE / LIST 分区，大租户单独落区。改动面大，业务层要不要改连接路由？
• 方案 C：应用层缓存——大租户列表页走 Redis 缓存 + 失效策略，绕开数据库。但这只是把问题从 DB 挪到了缓存，一致性怎么保？
• 方案 D：接受 2.4s 全表扫——给大租户列表页加个「稍等」的 loading，不做索引治理。2.4s P99 在 4000 QPS 的列表页上能撑住吗？

期望得到的答案形态：

1. 一个可执行的判断标准：在什么条件下（命中行数 / 租户数据占比 / 索引膨胀比）应该拆、什么条件下应该分区、什么条件下接受全表扫——别给「看情况」；
2. 拆索引 / 分区各自的代价量化：写放大百分比（4000 TPS 下）、索引存储膨胀、DDL 窗口和 MDL 风险；
3. 如果有「不拆不分区也能让优化器选对」的隐藏手段（比如 optimizer_switch 里某个 flag、或 8.0 的索引统计采样精度调整），请给出具体命令和适用边界；
4. 一个明确的「该做 / 不该做」结论，最好附一个类似「命中行 > X 且占比 > Y% → 拆；否则 → 分区；再否则 → 缓存」的决策树。

我 8 年 DBA 经验，写放大和 MDL 风险我能兜底，但「拆不拆、拆了值不值」这笔账我算不圆，想听社区里真在长尾多租户场景下做过取舍的同行的数据。