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

背景：我们正在管理一个 MySQL 8.0 多租户库，核心表约 2.8 亿行，单主 32C128G，头部租户占 41%。日常运行中，我们发现部分 SQL 的执行计划在不同租户参数下不一致，出现计划漂移（plan drift）现象。这导致部分 SQL 从索引扫描切换为全表扫描，造成性能下降。

现象：部分 SQL 的执行计划在不同租户参数下不一致，出现计划漂移（plan drift）现象。例如，头部租户走 idx_tenant_status，长尾租户被优化器判成全表扫描。这属于计划漂移，不是新增慢 SQL。

已尝试的排查与结果：

1. 已尝试使用 ANALYZE TABLE 更新统计信息，短期内问题缓解，但过几小时后又漂。
2. 检查了索引的覆盖性和选择性，确认索引存在且可服务该查询。
3. 尝试使用 FORCE INDEX 和 optimizer hint，但发现改动面较大，且部分 SQL 的执行计划仍会漂。

期望得到的答案形态：

1. 四条路径（FORCE INDEX / optimizer hint / 改 SQL / 加索引）的取舍标准与适用场景。
2. 如何建立可落线的治理规则与回滚机制。
3. 是否有可复用的治理方案或最佳实践。

引用：

• 问题 2258：讨论了执行计划漂移的治理路径。
• 文章 19：讲清了慢查询治理的正确顺序。
• 问题 2216：讨论了如何监测同一条 SQL 的执行计划突变。
• 文章 2685：讨论了执行计划稳定性指标的定义与事前拦截方案。