ETL批灌后执行计划漂移监测：不靠慢日志，如何量化同SQL的计划突变？

背景

我维护的MySQL 8.0.36集群（InnoDB，32C128G）存在ETL批灌导致的执行计划漂移问题。核心表t_billing_item（1.6亿行）每日02:00-06:00灌入3000-5000万行，白天OLTP点查P50≈4ms。但批灌后部分查询从走idx_tenant_period退化为全表扫描（P99从8ms飙到2.1s），且慢日志因噪音过多无法捕捉。

现象

1. 慢日志失效：批灌窗口内慢日志量激增（300+/秒），单晚达40GB，且漂移引发的2s级查询未被记录；
2. 计划突变无迹可寻：需业务方投诉后手动EXPLAIN才能发现，缺乏自动监测手段。

已尝试

• 调高long_query_time至5s减少噪音，但漏掉2s级退化查询；
• 试用performance_schema.events_statements_history_long，但表过大（5000万行）查询成本高；
• 调大innodb_stats_persistent_sample_pages至200，ANALYZE耗时从30s涨到3min，缺乏线上数据验证效果。

期望答案

1. 计划突变监测方案：
   • 有无生产验证的定时EXPLAIN比对方案？成本（CPU/IO/锁）和误报率如何？
   • 除slow_query_log外，哪些工具/方法能捕获计划突变（如optimizer_trace、FORCE INDEX等）？
2. 统计信息采样调优：
   • 1亿+行表调大innodb_stats_persistent_sample_pages的实际成本数据？
   • 是否出现「采样更准但优化器选错」的反例？
3. 计划稳定性保障：
   • 除ANALYZE外，如何实现ETL后计划锁定（如optimizer_switch参数、CLUSTERED INDEX等）？

（引用：id=2216《ETL批灌窗口慢日志被淹没后计划漂移》、id=2688《统计信息刷新时机》、id=3063《批跑免疫区治理方案》）