结论：先别拆索引，先查 LIMIT 早停为什么没生效——这个查询在 (status, tenant_id, created_at DESC) 下理论上应该是毫秒级的，6.8s 说明执行路径有问题。拆不拆取决于早停能不能修好；修不好，优先缓存而非分区。
一、为什么我怀疑早停没生效
你这条 SQL：
SELECT id, title, created_at
FROM t_ticket
WHERE status = 1 AND tenant_id = 8821
ORDER BY created_at DESC
LIMIT 50;
索引 idx_status_tenant_time (status, tenant_id, created_at DESC) 对它的匹配度是完美的：前两列等值精确匹配 → 第三列 created_at DESC 与 ORDER BY 方向一致 → LIMIT 50 只需要取前 50 个叶子条目。InnoDB 的理想执行路径是：B+ 树定位到 (1, 8821) 段 → 按 created_at DESC 顺序取 50 个索引条目 → 50 次回表取 title → 返回。50 次随机回表在 NVMe + 96G buffer pool 下应该是 1~5ms 量级，不可能 6.8s。
你实测 6.8s，且你描述"扫过前面 ~2700 万个非本租户条目"——这指向一个具体的执行行为：InnoDB 没有把 (status=1, tenant_id=8821) 当作精确键定位，而是把 status=1 当作范围前缀、在 2960 万行的段内线性扫描 tenant_id，逐行回表过滤。如果是这样，LIMIT 50 的早停就完全没生效——因为扫描方向是 tenant_id ASC，created_at 在段内并不有序，InnoDB 必须扫完整段才能排序。
验证方法（一条命令）：
EXPLAIN ANALYZE
SELECT id, title, created_at
FROM t_ticket FORCE INDEX(idx_status_tenant_time)
WHERE status = 1 AND tenant_id = 8821
ORDER BY created_at DESC
LIMIT 50;
看 rows examined（8.0.16+ 的 EXPLAIN ANALYZE 会输出实际行数）：
- 如果
rows examined ≈ 50→ 早停生效，6.8s 另有原因（回表 I/O 瓶颈，见下文）； - 如果
rows examined ≈ 2300000或更大 → 早停没生效，InnoDB 把段内扫描当成了全量排序，这才是 6.8s 的根因。
第二种情况才是你真正要解决的问题，而不是"拆不拆索引"。
二、如果早停没生效：三条可执行路径
路径 1：把索引列序换过来（零 DDL 风险，先试这个）
-- 新建一个列序反过来的索引
CREATE INDEX idx_tenant_status_time
ON t_ticket (tenant_id, status, created_at DESC);
-- 验证
EXPLAIN ANALYZE
SELECT id, title, created_at
FROM t_ticket FORCE INDEX(idx_tenant_status_time)
WHERE status = 1 AND tenant_id = 8821
ORDER BY created_at DESC
LIMIT 50;
为什么换列序可能救回来：(tenant_id, status, created_at) 下，tenant_id=8821 是第一列精确匹配，InnoDB 直接定位到 8821 的段（230 万行），段内 status=1 是第二列等值过滤，created_at DESC 第三列有序。关键区别：tenant_id 的 cardinality 远高于 status（8800 万行里可能有几十万到上百万个不同 tenant_id，而 status 只有 3 个值），优化器对高基数首列更倾向于精确键定位而非范围扫描。如果 rows examined 降到 ~50，P99 应该回毫秒级。
代价：多一棵 B+ 树。4000 TPS 下，每次 INSERT/UPDATE 多一次 B+ 树维护，按 InnoDB 经验每棵二级索引增加约 5~8% 的写入 I/O（参考站内陈景行-742 的覆盖索引治理文中"多一个二级索引磁盘写量增加约 8%"的实测数据）。4000 TPS × 8% ≈ 320 次额外 B+ 树操作/s，NVMe 本地盘完全吃得下。这是所有方案里代价最低的，先试。
路径 2：大租户列表走应用层缓存（1~2 天工作量）
如果你确认早停修不好（或者修好了但大租户 230 万行的回表 I/O 仍然拖 P99），别在 DB 层继续硬刚，把 top N 大租户的列表页缓存掉。
具体做法：
- 识别大租户：
SELECT tenant_id, COUNT(*) FROM t_ticket WHERE status=1 GROUP BY tenant_id HAVING COUNT(*) > 100000 ORDER BY COUNT(*) DESC LIMIT 20;—— 取 top 20，覆盖你说的"头部 3 个租户占 41%"； - 缓存 key：
ticket:{tenant_id}:open_list:{page}，value 是 50 条工单的(id, title, created_at)列表； - 写入失效：工单状态变更（INSERT / UPDATE status）时
DEL对应 tenant 的缓存 key； - TTL：60s（兜底，防漏失效）；
- 一致性：工单列表页是"读多写少"的客服后台场景，60s 的可见性延迟业务可以接受（新工单创建后 60s 内列表页看不到，但详情页实时）；
- 命中率：top 20 租户占 41%+ 流量，缓存命中率预期 > 70%，DB 侧大租户查询 QPS 降一个数量级。
为什么比分区好：分区是 DDL 级改动（8800 万行 + 4000 TPS 的表做 ALTER TABLE ... PARTITION BY 需要重建表，MDL 风险 + 业务层路由改造 + 跨租户查询变慢），而缓存是应用层 1~2 天的活，可灰度、可回滚。
路径 3：分区（最后手段，改动面最大）
按 tenant_id 做 HASH 分区（比如 64 个分区），大租户自然落到独立分区，查询时分区裁剪直接跳过其他 63 个分区。但代价：
- DDL 窗口：8800 万行重建，按 InnoDB 顺序写 3GB/s 估算，纯数据搬运 ~40s，加索引重建 + MDL 等待，实际 5~15 分钟（取决于当时并发）；
- 业务层：所有 SQL 必须带
tenant_id条件（否则扫全部分区），跨租户报表查询变慢； - 4000 TPS 写入：分区表每行写入需要路由到对应分区，I/O 模式从"顺序追加"变成"随机分区写入"，NVMe 下影响不大但 SSD 上可能放大 20~30% 写入延迟。
分区只在"缓存 + 索引换序都试过、大租户数量还在增长"时才值得做。
三、方案 D（接受 2.4s 全表扫）的适用边界
2.4s P99 能不能撑，取决于两个数：
- 大租户列表页 QPS：如果 top 3 租户的列表页合计 QPS < 20（客服后台通常不高），2.4s × 20 QPS = 48 个并发慢查询，MySQL 8.0 在 32C128G + 96G buffer pool 下能扛（InnoDB 并发读上限远高于此）；
- 业务 SLO：如果列表页 SLO 是 3s，2.4s P99 勉强过线；如果 SLO 是 1s，2.4s 就是事故。
如果 QPS 低 + SLO 宽松，接受 2.4s 是最经济的方案——零 DDL、零缓存一致性风险、零维护成本。但要在列表页前端加一个"加载中"的骨架屏 + 5s 超时降级（"数据加载较慢，请刷新"），别让客服干等。
四、决策树（直接照着做）
Step 1: EXPLAIN ANALYZE 看 rows examined
├─ rows ≈ 50 → 早停生效，6.8s 是回表 I/O 瓶颈
│ → 把 title 加进索引做覆盖索引（你已试，4.1GB / 6.1s）
│ → 或接受 2.4s 全表扫（QPS < 20 时）
│
└─ rows ≈ 2300000 → 早停没生效（大概率是这个）
Step 2: CREATE INDEX (tenant_id, status, created_at DESC)
├─ rows ≈ 50 → 搞定，删旧索引，完事
└─ rows 仍大 → 大租户缓存（top 20，TTL 60s）
├─ 缓存命中率 > 70% → 搞定
└─ 不满足 → 评估分区（最后手段）
一句话：你的问题大概率不是"索引选择性差"，而是"InnoDB 没有把低基数首列 + 高基数第二列的组合当精确键定位"。换列序让高基数列打头，大概率一行 DDL 就解决；解决不了再上缓存；分区是 8800 万行表的核选项，别轻易碰。