MySQL LTS与创新版本迁移窗口的评估清单

MySQL 选 LTS 还是 Innovation，关键不在“哪个版本更新”，而在团队能不能承受相应的升级频率和行为变化。官方当前把 8.4、9.7 作为 LTS 线路，同时保留更快的 Innovation 线路；LTS 适合需要较长支持周期的生产基线，Innovation 适合测试自动化成熟、希望更早使用新能力的团队。

官方资料：https://dev.mysql.com/doc/refman/9.7/en/mysql-releases.html

先判断目标版本线，再谈迁移窗口

MySQL 官方说明，LTS 在一个系列内尽量保持行为稳定，Innovation 则会带来新功能、弃用、移除和行为调整；Innovation 的支持也会随着下一条 Innovation 版本推进。因此，“能装上”不等于“适合长期运行”。如果业务每季度只能安排一次数据库变更，LTS 更容易形成可控基线；如果平台具备自动化测试、预发布集群和快速修复能力，Innovation 才有现实价值。

当前还要注意版本编号变化：MySQL 9.7 是旧式连续编号的最后一条发布线，后续 Innovation 和 LTS 将使用 YY.M 日历版本。版本号变化会影响镜像标签、包仓库选择和监控规则，应该提前写入发布清单。

把应用兼容性拆成三张表

第一张表记录连接器：Java、Go、Python 或 PHP 驱动的版本、认证插件、TLS 参数和连接池初始化方式。第二张表记录 SQL：新保留字、弃用语法、隐式类型转换、字符集和排序规则。第三张表记录运行结果：核心查询的执行计划、锁等待、复制延迟和错误日志。把三张表合并成“通过、观察、阻断”三种状态，迁移讨论会会比单纯对照版本号更有效。

# 只在隔离环境执行，先记录目标实例身份和当前版本
mysql -Nse "SELECT VERSION(), @@version_comment;"
# 迁移前导出核心对象定义，便于比较表、视图和存储程序变化
mysqldump --no-data --routines --events app_db > schema-before.sql
# 记录关键查询计划；生产环境不要用未经筛选的全库 SQL
mysql -e "EXPLAIN FORMAT=JSON SELECT id FROM orders WHERE customer_id=42 ORDER BY created_at DESC LIMIT 20;" app_db

这里的命令只是检查入口，不代替 MySQL Shell Upgrade Checker 或完整回归。尤其要把“执行计划变了但延迟没有变”和“延迟只在高峰变差”区分开，前者可观察，后者可能直接阻断发布。

选择同线升级、跨 LTS 或 Innovation 灰度

官方升级文档列出了原地升级、逻辑导入导出和复制拓扑升级等方式。生产环境更稳妥的顺序通常是：先做同流量的预发布副本，再让新版本跟随复制或蓝绿链路追数据，最后只切换一小部分读流量。不要把跨 Innovation 的降级当成普通重启；官方说明 Innovation 降级需要逻辑 dump/load，回滚前必须确认新版本特性没有写入不可逆的数据结构。

把迁移窗口拆成四道可验证的门

第一道门是驱动和认证，确保连接池能建立新连接；第二道门是 SQL 和计划，跑完高频读写、事务、批处理和报表查询；第三道门是复制、备份与恢复，确认 GTID、延迟、备份可读且恢复时间可接受；第四道门是灰度和回滚，预先定义错误率、P95 延迟、锁等待和复制延迟的停止阈值。

我会把“回滚截止时间”单独写进变更单：在新版本产生写入之后，旧版本是否仍能接收这些数据；如果不能，就只能保留逻辑导出和恢复路线，不能把切回旧节点称为回滚。这个边界比发布按钮本身更值得评审。

常见问题

MySQL 8.4 LTS 是否必须马上迁移到 9.7 LTS

不必仅因为 9.7 已发布就立即切换。先确认 8.4 的支持计划、驱动兼容和业务收益，再用同流量环境验证 9.7。

Innovation 版本能不能直接用于生产

官方将其视为生产级线路，但它要求更高的测试和升级频率。没有持续回归和快速修复能力时，不宜把核心库作为第一落点。

迁移前最容易漏掉什么

连接器和认证配置最常被忽略，其次是新保留字、执行计划变化，以及只在高峰期出现的复制延迟。

最终清单应留下四个结果：目标轨道、已关闭的兼容性阻断项、灰度观察窗口、明确可执行的回滚路径。这样版本迁移才是工程决策，而不是一次临时换包。