TiDB 从 5.4 升级到 7.1 跨越了多个大版本，优化器内核的成本模型和规则引擎发生了迭代，导致部分 SQL 执行计划出现变化属于预期行为。
先说结论：执行计划突变主要源于优化器升级带来的成本计算差异，优先使用 SQL Bind 固定计划可快速止血。
- 先定位：通过慢查询日志锁定计划变化的具体 SQL
- 先处理：使用 CREATE BINDING 强制指定旧版本执行计划
- 再验证：执行 EXPLAIN 对比算子类型确认绑定生效
命令速用版
直接通过 SQL 绑定功能恢复原有执行计划，无需回滚版本。
SHOW PLAN_BINDS;
CREATE BINDING FOR <原 SQL> USING <带 Hint 的 SQL>;
ADMIN CAPTURE BINDINGS;为什么会这样
TiDB 7.1 版本默认启用了更激进的新成本模型，且优化器规则相比 5.4 版本有明显增减。
5.4 到 7.1 之间经历了 6.x 系列的优化器重构，包括连接重排序（Join Reorder）逻辑改进和统计信息采样策略调整。公开资料中没有看到可靠的量化数据表明性能一定提升或下降，但计划形状改变是版本升级的常见副作用。
分步处理
按照定位、绑定、统计信息更新的顺序处理，避免盲目调整参数。
- 锁定问题 SQL：查询 INFORMATION_SCHEMA.SLOW_QUERY 表，找到升级后耗时突增的语句。
- 对比执行计划：分别在测试环境 5.4 和 7.1 版本对该 SQL 执行 EXPLAIN，记录算子差异。
- 创建绑定：在 7.1 集群使用 CREATE BINDING 语句，将 SQL 绑定到 5.4 版本的优秀计划或指定 Hint。
- 更新统计信息：执行 ANALYZE TABLE 命令，确保优化器基于最新数据分布计算成本。
怎么验证是否生效
通过 EXPLAIN 命令检查 Plan 字段是否包含 binding 标识，并观察业务延迟是否回落。
- 执行 EXPLAIN <SQL>，检查输出中是否显示使用了 Binding。
- 监控 Grafana 面板中该 SQL 的 Query Duration 指标。
- 检查 TiDB 日志中是否有 Plan Bind 相关的加载记录。
常见坑
统计信息过期和绑定语句语法错误是导致处理失效的主要原因。
- 绑定语句中的表名必须包含数据库名，否则可能匹配失败。
- 升级后未重新收集统计信息，导致优化器基于旧直方图计算成本。
- 部分 Hint 语法在不同版本间存在兼容性差异，需查阅对应版本文档。
常见问题
升级后能否直接回滚版本？
不建议直接回滚，数据兼容性风险高于计划突变风险。
统计信息会自动更新吗？
TiDB 有自动分析机制，但大版本升级后建议手动触发一次 ANALYZE。
绑定计划会影响其他 SQL 吗？
SQL Bind 仅对精确匹配或模板匹配的特定 SQL 生效，不影响全局。
参考来源
- TiDB Official Documentation, Release Notes, https://docs.pingcap.com/tidb/stable/release-notes
- TiDB Official Documentation, SQL Plan Management, https://docs.pingcap.com/tidb/stable/sql-plan-management