数据库升级易致执行计划退化，主因优化器逻辑变更、统计信息策略调整及默认参数变化；需通过预发压测、计划比对和文档核查三步验证，并可临时绑定计划规避风险。
数据库版本升级后，执行计划可能发生意外变化，导致查询变慢甚至超时。这不是偶然现象，而是优化器逻辑、统计信息收集方式、默认参数或代价模型调整带来的直接结果。
优化器行为变更最常引发计划退化
新版本通常会改进查询优化器的决策逻辑，比如引入更精确的基数估算方法、支持新的连接算法（如Batched Nested Loop Join），或调整索引扫描与全表扫描的代价阈值。这些改动在多数场景下提升性能，但对某些特定SQL（尤其是依赖旧版启发式规则的复杂查询）可能生成次优计划。
- Oracle 12c 引入自适应执行计划，可能在运行时切换计划分支，但监控和诊断门槛提高
- PostgreSQL 14 增强了并行查询的启动条件判断，部分小数据量查询反而被强制并行，增加调度开销
- SQL Server 2022 默认启用“参数敏感计划优化”（PSP），对参数嗅探敏感的存储过程可能出现非预期计划缓存
统计信息收集策略变化影响基数估算准确性
新版数据库常调整自动统计信息更新的触发阈值、采样率或列关联性建模能力。若统计信息未及时刷新或直方图粒度不匹配，优化器可能严重低估/高估中间结果集大小，进而选择错误的连接顺序或访问路径。
- MySQL 8.0 默认启用red">innodb_stats_auto_recalc=ON，但大表DDL后仍需手动ANALYZE TABLE确认
- SQL Server 新版本对字符串列默认启用“增量统计信息”，但仅限分区表，普通表仍需全量更新
- 避免依赖默认采样率：对倾斜数据，显式指定FULLSCAN或PERSIST_SAMPLE_PERCENT更可靠
绑定执行计划可临时规避风险
在升级验证期，对核心业务SQL提前固化执行计划，是控制风险的有效手段。不同数据库提供机制略有差异，但目标一致：绕过优化器重编译，复用已验证的高效计划。
- Oracle 使用SQL Plan Baseline或SQL Patch锁定计划，支持带条件启用（如仅对特定绑定变量值）
- SQL Server 通过Query Store强制执行计划，或使用USE PLAN提示嵌入执行计划XML
- PostgreSQL 可借助pg_hint_plan插件，在SQL中添加/*+ IndexScan(t idx_name) */等提示干预
- 注意：计划绑定是临时措施，长期应分析退化根因，而非永久依赖提示
升级前必须做的三件事
不靠运气，靠验证。版本升级不是运维操作，而是数据库能力迁移项目。
- 在预发环境完整回放生产负载（至少7天典型流量），重点监控慢查询突增、执行计划哈希值变更、逻辑读飙升
- 导出关键SQL的旧版执行计划（含Predicate信息、Actual Rows与Estimate Rows对比），升级后逐条比对
- 检查新版文档中的“Deprecated Features”和“Incompatible Changes”章节，确认是否涉及当前使用的Hint、函数或隔离级别
