MySQL 8.0 同一条 SQL 白天走索引、凌晨批跑时突变为全表扫描——统计信息刷新时机到底怎么定？

背景

我们有一个多租户的数据库系统，核心表 t_invoice_item 有 2.3 亿行数据，每天凌晨 2 点到 5 点执行批处理任务，将大量数据从状态 UNBILLED 灌入到已处理状态。批处理任务结束后，执行 ANALYZE TABLE t_invoice_item 来刷新统计信息。

现象

在白天，执行查询 SELECT id, amount, status FROM t_invoice_item WHERE tenant_id = ? AND billing_period = ? AND status = 'UNBILLED' ORDER BY id LIMIT 500; 时，查询会走 idx_tenant_period 索引，执行时间在 5ms 以内。但在凌晨批跑任务结束后，执行相同 SQL 时，会突变为全表扫描，执行时间飙升至 120ms，甚至更高。

已尝试的排查与结果

1. 执行 ANALYZE TABLE t_invoice_item 后，查询会立即走索引，但 2–4 小时后（通常在批跑窗口附近）再次漂移。
2. 检查统计信息，发现 UNBILLED 占比从白天的 12% 掉到凌晨的 3%，这导致优化器选择全表扫描。
3. 尝试在批处理任务结束后执行 ANALYZE TABLE，但发现统计信息刷新后，UNBILLED 占比恢复，但执行计划仍可能漂移。
4. 使用 EXPLAIN 检查执行计划，发现执行计划确实发生了变化。

期望得到的答案形态

1. 统计信息刷新的时机应该如何确定？
2. 如何避免执行计划漂移？
3. 是否有自动化方案来监控和修复执行计划漂移？
4. 在无法修改 SQL 或表结构的情况下，有哪些轻量级的方案可以尝试？

引用

• 问题 1033：MySQL 8.0 同一条 SQL 白天走索引、凌晨批跑时突变为全表扫描——统计信息刷新时机到底怎么定？
• 问题 2216：ETL 批灌窗口慢日志被淹没后「计划漂移」失明：不靠 slow_query_log，你们线上怎么监测同一条 SQL 的执行计划突变？