MySQL 8.0.32→8.0.36 升级后同一批 SQL 执行计划变了（JOIN 顺序、索引选择都变了）：怎么系统性地回归验证，而不是靠肉眼逐条 EXPLAIN 对比？

背景

我负责一套 MySQL 8.0.32（InnoDB，主从架构，核心库 8 张表、总数据量约 3 亿行）的日常运维。最近一次 minor 升级（8.0.32 → 8.0.36）后，业务侧反馈「部分报表 SQL 变慢了」，我拉了慢日志对比，发现同一批 SQL 的执行计划确实发生了变化：

• 一条 4 表 JOIN 的报表查询，JOIN 顺序从 t_a → t_b → t_c → t_d 变成了 t_b → t_a → t_d → t_c，P95 从 200ms 涨到 1.8s；
• 另一条原本走 idx_tenant_time (tenant_id, created_at) 的查询，升级后改走了全表扫描（表约 5000 万行）；
• 还有一条 GROUP BY 查询，升级后从 Using index for group-by 变成了 Using temporary; Using filesort。

现象与卡点

我理解 8.0.32 → 8.0.36 之间优化器有多次改动（hash join 默认开启、derived condition pushdown 行为调整、histogram 采样策略变化等），所以执行计划变化不算「bug」，但我缺一套系统性的回归验证流程，目前只能：

1. 逐条 EXPLAIN 对比升级前后的计划（核心 SQL 有 60+ 条，肉眼对比效率极低且容易漏）；
2. 对变慢的 SQL 逐条调 optimizer_switch 或加 hint 回退（治标不治本，下次升级还得再来一遍）；
3. 跑 ANALYZE TABLE 重新收集统计信息，部分 SQL 恢复了，但 JOIN 顺序那条还是没回来。

具体卡点：

• 怎么批量回归：有没有比「逐条 EXPLAIN 肉眼对比」更系统的方法？比如用 performance_schema 抓升级前的 SQL 指纹 + 计划，升级后回放对比？或者用 mysql_test / 自研 SQL 回放工具跑「计划指纹 diff」？
• 统计信息：minor 升级后是否需要全量 ANALYZE TABLE？histogram 是自动重建还是手动 ANALYZE TABLE ... UPDATE HISTOGRAM？8.0.36 的 histogram 采样算法和 8.0.32 有差异吗？
• 优化器开关：哪些 optimizer_switch 项在 8.0.32→8.0.36 之间行为发生了变化？有没有官方 changelog 里明确标注「plan-affecting」的改动清单？
• 长期策略：如果团队不想每次都「升级后逐条排查」，有没有办法在升级前用 staging 环境做一轮「计划指纹对比」（比如用 EXPLAIN FORMAT=JSON 做 diff，或用 optimizer_trace 抓决策路径）？

已尝试

• ANALYZE TABLE 全库跑了一遍，3 条 SQL 恢复了，JOIN 顺序那条没恢复；
• 对 JOIN 顺序那条手动加了 STRAIGHT_JOIN，性能恢复了但语义上锁死了 JOIN 顺序，后续表结构变化可能再出问题；
• 翻了 MySQL 8.0.33 / 8.0.34 / 8.0.35 / 8.0.36 的 Release Notes，找到了几条「optimizer」相关改动但没有系统整理哪些是 plan-affecting；
• 社区 id=1033 的讨论（统计信息刷新时机）给了「histogram 采样 + 统计信息更新时机」的方向，但我的场景是「升级导致计划变化」而不是「数据量变化导致计划漂移」，角度不同。

期望的回答形态

希望有同学能给出：

1. 一套可复现的回归流程：升级前抓什么（SQL 指纹 + EXPLAIN JSON + optimizer_trace？）→ 升级后怎么回放 → 怎么自动 diff 计划变化（工具或脚本都行）；
2. 8.0.32→8.0.36 之间已知的 plan-affecting 改动清单（哪怕只列出「你踩到的那几条」也行，附 Release Notes 链接）；
3. 统计信息 / histogram 在 minor 升级后的正确处理方式（要不要全量 ANALYZE、histogram 是否自动重建、有没有已知的采样算法变化）；
4. 长期策略：如果你们团队有「升级前 staging 计划指纹对比」的实践，请分享流程、工具和耗时。

如果你们最后选择「不升 minor，只升 patch」或「升级后靠 optimizer_switch 逐条回退」，也请说下原因和代价，我这边好权衡。