超级管理员
楼主
OCI 的发布说明里有一条容易被忽略但影响不小：MySQL 9.7 LTS 取代 MySQL 8.4 LTS，成为新建数据库系统的默认版本。
这件事的实际影响 如果你用托管服务并且习惯“用默认值”，那么从现在开始新建的实例就是 9.7 了。如果还有自动化脚本、IaC 模板、部署文档里写着 8.4，需要更新——否则新旧实例版本不一致，排查问题时会踩坑。
LTS 切换是个信号 MySQL 8.0 到 8.4 LTS 再到 9.7 LTS，版本节奏在加快。对企业来说，LTS 版本的选择直接影响未来三五年的维护计划。
升级前要做的
- 先查兼容性。9.x 相比 8.x 有废弃和移除的特性，尤其是一些旧的函数、变量和字符集默认值。用官方的升级检查工具先跑一遍。
- 重点看 SQL 模式变化。某些在 8.x 下能跑的 SQL 在 9.x 下可能报错或行为不同，特别是 GROUP BY 的隐式排序、保留字这些。
- 检查 ORM 和驱动的兼容版本。老版本的 JDBC、mysql-connector-python 可能不支持新的认证插件。
- 复制拓扑要单独规划。主从版本混跑是有条件支持的，但要先确认你的拓扑在支持矩阵内。
建议的升级路径
- 先在测试环境跑完整回归，重点是复杂查询的执行计划和性能。新版本的优化器行为可能变化，某些查询会变快也有些会变慢。
- 用生产流量的影子副本做压力测试，对比关键指标。
- 准备好回滚方案。数据库升级的回滚通常意味着从备份恢复，要确认备份能恢复且恢复时间可接受。
- 分批推进。非核心业务先升，观察一周，再上核心。
不要急着升 新成为默认的 LTS 不等于立刻必须升级。8.4 LTS 仍在支持期内。判断标准是你的业务有没有遇到 8.4 解决不了的问题，或者 8.4 的支持期是否临近结束。
对于稳定运行的系统，“能不动就不动”往往是对的。数据库升级的风险收益比要看具体情况，别被版本号推着走。
顺带提醒 现在很多开发者的本地环境还是 5.7 或 8.0。开发环境和生产环境版本差异过大，是很多“本地好好的线上就出问题”的根源。至少让开发环境的 MySQL 大版本跟生产对齐。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。