MySQL 8.0 多租户库执行计划漂移后怎么「批量固化」：FORCE INDEX / optimizer hint / 改 SQL / 加索引四条路怎么取舍，有没有可落线的治理规则与回滚机制？

结论先行

在 MySQL 8.0 多租户库中，执行计划漂移是一个常见但高风险的问题，尤其在租户之间隔离性不强时。 本文将讨论 FORCE INDEX、optimizer hint、改 SQL、加索引四条路的取舍，以及如何建立可落线的治理规则与回滚机制。

背景

我们有一个 MySQL 8.0 多租户库，每个租户的数据在同一个物理表中，通过 schema 或 tenant_id 字段进行隔离。随着数据量的增长，执行计划漂移现象愈发严重，导致部分租户的查询性能下降。

现象

1. 查询性能不稳定，P99 延迟波动大。
2. 执行计划频繁变化，无法预测。
3. 优化器选择的索引与实际业务需求不符。

已尝试的排查与结果

1. FORCE INDEX：强制指定索引，短期内提升了部分查询性能，但增加了维护成本。
2. optimizer hint：通过 hint 指定执行计划，效果与 FORCE INDEX 类似，但灵活性较差。
3. 改 SQL：对 SQL 进行重构，优化查询逻辑，部分查询性能有所提升。
4. 加索引：新增了多个索引，但索引过多导致维护成本增加，且执行计划依然不稳定。

期望得到的答案形态

1. 四条路的优缺点对比，适用场景。
2. 可落线的治理规则，如何批量固化执行计划。
3. 回滚机制的设计，如何在执行计划变化时快速恢复。

引用

• [文章] 《Java 21 虚拟线程被 synchronized 钉死：一次 10 万并发压回 8 个物理线程的排查》(id=611)
• [文章] 《JDK 21 虚拟线程上线后 P99 不降反升：一次 synchronized pinning 拖垮 ForkJoinPool 的排查与修复》(id=669)
• [提问] 《JDK21 虚拟线程高并发下 CPU 只有六成：怎么系统性拆出 carrier 调度延迟占比》(id=864)