MySQL 计划漂移治理的「度量前置」：3000+ 查询模板多租户库，怎么把「执行计划稳定性」定义成一个可计算、可基线、能事前拦截的指标？

背景

我是一名技术文档工程师，日常在帮 30 人数据团队搭指标体系（上一篇《指标字典不是文档是断言》讲过指标断言的落地）。现在接手一个新课题：给一个 MySQL 8.0.36 / InnoDB 多租户核心库（单主 32C128G，核心表 2.8 亿行，头部租户占 41%，慢日志日均 1500+ 条）搭一套**「执行计划稳定性」度量体系**。

站内的讨论我基本都读过了：2216 问「怎么监测计划突变」、2258 问「四条固化路线怎么取舍」、1551/1486 问「告警阈值静态还是动态」、208 给了统计信息漂移的根因案例。但这些都默认「计划稳定性」已经被定义成指标了——没人正面回答：这个指标本身怎么算。

现象 / 卡点

我试过三种朴素的「稳定性」定义，全部踩坑：

1. plan_change_rate = 计划变更次数 / 总查询次数。问题：分母是查询次数，一条一天跑 10 万次的模板和一条一天跑 3 次的模板权重差 5 万倍；而且「变更」怎么算——EXPLAIN 输出里 rows 估算值每次跑都漂，直接 diff 全是噪声。
2. per-template 计划签名集合的基数。问题：签名归一化怎么做？MySQL 的 EXPLAIN 里 type、key、Extra 里 Using temporary; Using filesort 的出现顺序会随优化器版本变，直接 hash 整个 EXPLAIN JSON 会假阳性爆炸。
3. P99 延迟的环比。问题：这是结果指标不是原因指标——延迟涨了 3 倍可能是索引没选对，也可能是 buffer pool 被 ETL 冲掉、也可能是上游连接池打满，三个根因对应完全不同的动作，用同一个指标分不清。

已尝试的排查与结果

• 用 performance_schema.events_statements_history_long 抓 fingerprint 级执行记录，digest_text 做模板归一化——可行，但 3000+ 模板 × 多租户，存储和聚合查询本身就有压力；
• 用 information_schema.processlist + 自定义采样脚本，每 5 分钟抓一次活跃 SQL 的 EXPLAIN——抓到的是「当前正在跑的」，对低频模板（一天跑 3 次）覆盖不到；
• 对比 208 那篇的 ANALYZE TABLE 修复路径，发现统计信息刷新后计划确实变了，但没有指标告诉我「这个变化是改善还是恶化」——还是靠人肉 EXPLAIN 对比。

期望得到的答案形态

1. 指标定义：「执行计划稳定性」在你的团队里到底怎么算？分子分母是什么？有没有可复现的公式或 SQL？
2. 签名归一化：怎么从 EXPLAIN / EXPLAIN ANALYZE 输出里提取「结构性变更」而过滤掉 rows 估算值、Extra 顺序这类噪声？具体到哪些字段参与 hash、哪些排除？
3. 基线策略：per-template 基线窗口多长？头部租户和长尾租户要不要分开算基线？怎么避免「凌晨 ETL 窗口」把基线拉飞？
4. 事前拦截：这个指标怎么和发布流程 / CI 挂钩——比如一次 DDL 或 minor 升级前，怎么批量回归 3000 条模板的计划签名，diff 超阈值就 block？
5. 一个真实案例：你的团队里，这个指标在事故之前抓到了什么、拦截了什么？比「事后复盘」值钱 10 倍。

我接受「目前没有现成指标，但有一套可落地的近似方案」这种回答——比「用 Prometheus 看 P99 就行了」有用。