mysql 5.7已停更（eol 2025-10-01），不再获安全补丁与维护，生产环境使用即裸奔；升级至8.0必须做兼容性验证，否则会因保留字（如rank）、移除模式（no_auto_create_user）、认证插件（caching_sha2_password）等导致硬性报错。
新项目直接选 MySQL 8.0；存量 5.7 系统升级前必须做兼容性验证，不能跳过。
MySQL 5.7 已停更，不是“不推荐”，是“不能用”
MySQL 5.7 的官方生命周期（EOL）已于 2025-10-01 正式结束。这意味着：
- Oracle 不再发布任何安全补丁——哪怕爆出 CVE-2026-XXXX 这类高危漏洞，也无人修复
- 社区不再维护，所有 bug 报告、文档更新、测试覆盖全部停止
- 云厂商（如阿里云 RDS）虽仍提供 5.7 实例，但仅用于存量迁移过渡，不新增功能增强
你在 2026 年装 5.7，等于在生产环境裸奔。这不是性能优劣问题，是合规与风控底线。
MySQL 8.0 默认行为会直接 break 旧 SQL
升级不是“换二进制文件”那么简单。以下几类写法在 5.7 能跑，在 8.0 会报错：
-
CREATE TABLE user (id INT, rank INT)→ERROR 1064：因为rank是 8.0 新增保留字，必须写成`rank`或改名 -
GRANT SELECT ON db.* TO 'u'@'%'→ERROR 1227：8.0 移除了NO_AUTO_CREATE_USER模式，GRANT不再隐式建用户，需先CREATE USER - 备份恢复时含
sql_mode=NO_AUTO_CREATE_USER的语句 → 启动失败或导入中断 - 客户端连接报
Authentication plugin 'caching_sha2_password' cannot be loaded→ 驱动太老，比如mysql-connector-python
别指望“先上线再修”。这些不是 warning，是硬性 syntax error 或 auth failure，会卡在部署第一关。
窗口函数和 CTE 不只是“语法糖”，是开发效率分水岭
以“每个部门薪资 Top 3 员工”为例：
- 5.7 写法：
@row := IF(@dept = dept_id, @row + 1, 1)+ 子查询嵌套，逻辑绕、难调试、并发下易出错 - 8.0 写法：
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC)，一行解决，结果确定，执行计划可读
这类差异不是“学着用”，而是直接影响代码可维护性。你写的每一条复杂报表 SQL，在 8.0 里少写 30%–50% 行数，且性能更稳（实测 10 万行数据快约 30%）。
云上用 RDS MySQL 8.0 几乎没成本，自建才真麻烦
如果你用阿里云 RDS：
- 创建实例默认就是 8.0 最新版，无需手动编译、调参、打补丁
-
ALTER USER ... IDENTIFIED WITH mysql_native_password这类降级操作，RDS 控制台点两下就能开白名单+切认证方式 - 从 5.7 升级到 8.0 支持一键大版本升级，业务中断控制在秒级（实测平均 12 秒）
- 自带 DAS（数据库自治服务），能自动识别
rank等字段冲突、给出重命名建议
真正要花时间的，从来不是“怎么装 8.0”，而是翻出三年前写的存储过程，把里面所有 @var 变量模拟的排名逻辑，替换成 ROW_NUMBER()——这个动作没法跳过，越拖越难。
