计划缓存是否会造成升级前后 SQL 客户端执行效率分化？
计划缓存也可能在某些情况下导致性能问题或者执行效率分化，特别是在升级前后或者在数据库负载模式发生变化时
升级后计划缓存策略、规则或实现变化，会因缓存命中、执行计划优劣、编译开销差异，导致前后 SQL 执行效率出现分化
迁移升级建议先在小规模环境做充分的兼容性测试，特别是SQL语法、自增主键、事务隔离级别这几个方面。如果是分库分表迁移，要注意全局唯一ID的生成方式，推荐用 AUTO_RANDOM 替代自增主键。
理论上应该会出现分化
在生产环境升级前，在测试环境中进行充分的测试，评估升级对查询性能的影响
使用 TiDB 的监控工具（如 Grafana 和 Prometheus）来监控计划缓存的命中率、缓存失效次数等指标。
升级前建议先看 release notes，大版本之间有些参数默认值会变。另外生产环境升级建议先在一个 TiKV 节点灰度验证，观察一段时间没问题再全量升级。
可能需要重新生成或清除旧的计划缓存，尤其是在统计信息有重大变化后。可以使用FLUSH STATUS 命令来重置统计信息并尝试重新生成计划缓存
计划缓存全部失效，SQL 重新解析、生成新版本执行计划，首次执行耗时飙升；新优化器生成的计划优劣不一，出现部分 SQL 变快、部分变慢的分化。
TiDB 的兼容性跟执行计划的生成机制有关，同样的 SQL 在 MySQL 和 TiDB 上的优化器决策可能不同，特别是子查询和 JOIN 的处理方式。迁移前建议用 SQL Plan Management 做下 SQL 兼容性扫描。
如果升级后没有正确地更新或重新收集统计信息，这可能会影响优化器的决策，从而影响查询的执行计划选择和效率。