应优先选用MySQL官方长期支持版本（LTS），如8.0.x（支持至2026年），避开已EOL的5.7等旧版；升级需关注认证插件、SQL模式等不兼容变更，并在测试环境充分验证。
选择合适的 MySQL 版本，核心是平衡稳定性、功能需求、安全支持和运维成本。官方长期支持版本（LTS）通常是生产环境的首选，而非最新版未必合适，老旧版本则面临安全与兼容风险。
优先考虑官方长期支持版本（LTS）
MySQL 官方对每个大版本提供约 5 年的支持周期（含安全更新和关键缺陷修复）。例如 MySQL 8.0 自 2018 年发布后，支持将持续至 2026 年；而 5.7 已于 2023 年 10 月结束生命周期（EOL），不再接收任何更新。
- 生产系统应避开已 EOL 的版本（如 5.6、5.7），避免无补丁漏洞风险
- 新项目建议直接采用 8.0.x（当前主流 LTS），兼顾性能优化（如原子 DDL）、安全增强（默认强密码策略、角色管理）和现代特性（JSON 增强、窗口函数、CTE）
- 若依赖旧应用或中间件（如某些老版本 MyBatis、Druid），需提前验证兼容性，而非单纯降级版本
谨慎评估 MySQL 8.0 升级门槛
8.0 相比 5.7 有若干不兼容变更，需针对性检查：
- 默认认证插件从 mysql_native_password 改为 caching_sha2_password，部分旧客户端（如 MySQL 5.7 客户端、低版本 JDBC 驱动）连接失败，需显式配置或调整用户插件
- 系统表迁移为 InnoDB，mysql.user 等表结构变化，备份恢复工具（如 mydumper）需升级适配
- SQL 模式默认更严格（如 STRICT_TRANS_TABLES 启用），可能暴露原有隐式转换问题，建议在测试环境开启 sql_mode = '' 逐步校验
云环境与发行版需额外注意
阿里云 RDS、腾讯云 CDB、AWS RDS 等托管服务通常提供定制化 MySQL 版本（如 AliSQL、TDSQL 分支），它们在原生基础上增强监控、高可用或审计能力，但可能滞后于社区最新小版本。
- 使用云数据库时，以服务商公布的“推荐稳定版”为准，不必强求同步社区最新 patch
- 避免混用不同厂商分支（如将 RDS 备份导入自建 Percona Server），存在元数据或日志格式差异风险
- 若选用 Percona Server 或 MariaDB，需明确替代动机（如热备份增强、线程池优化），并确认团队具备对应维护能力
小版本升级原则：只升不降，小步快跑
同一主版本内（如 8.0.x → 8.0.y），小版本升级风险较低，但不可跳过中间关键补丁：
- 优先升级到当前主版本的最新 GA 小版本（如 8.0.34+），它包含累积的安全修复与稳定性改进
- 跳过多个小版本（如 8.0.23 → 8.0.33）可能遗漏中间的重要修复，建议逐级升级并充分测试
- 升级前务必在相同硬件/配置的测试环境执行完整回归：包括慢查询、连接池行为、备份恢复、主从同步延迟等
