必须经5.6中转升级。因5.5与5.7存在mysql.user表结构、InnoDB文件格式及SQL模式三处底层不兼容，仅5.6能承上启下；跳过将致mysql_upgrade失败、服务无法启动或复制中断。
不能直接升级。 MySQL 官方明确不支持 5.5 → 5.7 跳过 5.6 的跨大版本升级，生产环境强行跳升大概率导致 mysql_upgrade 失败、系统表结构错乱、复制中断，甚至服务无法启动。
为什么必须经过 5.6 中转
5.5 和 5.7 之间存在三处底层不兼容，5.6 是唯一能承上启下的过渡版本：
-
mysql.user表在 5.6 中新增了plugin字段，5.5 数据无法被 5.7 直接识别，报错如Unknown column 'plugin' in 'mysql.user' - 5.6 引入
innodb_file_format = Barracuda和innodb_large_prefix强制校验，5.5 的ibdata1文件格式不被 5.7 启动时接受 - SQL 模式变化剧烈：5.5 默认允许
NO_ZERO_DATE，5.6 开始警告，5.7 默认启用STRICT_TRANS_TABLES和ONLY_FULL_GROUP_BY，跳过 5.6 会让这些模式变更“突袭”上线，触发大量 GROUP BY 或隐式类型转换失败
5.5 → 5.6 升级时最关键的实操动作
这步最易出问题，必须手动干预：
- 升级前执行
mysqldump --all-databases --skip-triggers --routines --events > full.sql，不要依赖物理拷贝——5.5 的ibdata1在 5.6 下无法直接复用 - 启动 5.6 时加参数
--skip-grant-tables --skip-networking，再运行mysql_upgrade -u root -p --force，否则权限系统初始化失败，后续所有操作被拒 - 确认升级后执行
SELECT VERSION(), @@innodb_file_format, @@sql_mode;，确保innodb_file_format变为Barracuda，且sql_mode中不含NO_ZERO_DATE - 临时关闭
STRICT_TRANS_TABLES和ONLY_FULL_GROUP_BY（在 5.6 的my.cnf中注释或移除），避免启动即拒绝加载旧表定义
5.6 → 5.7 升级前必须清理的 SQL 模式陷阱
5.7 默认开启严格模式，很多 5.5/5.6 下能跑的查询会直接报错：
- 典型报错：
Expression #2 of SELECT list is not in GROUP BY clause，对应语句如SELECT id, name FROM user GROUP BY id（name未聚合也未出现在GROUP BY） - 升级前应在 5.6 环境中提前测试并修正这类 SQL，或临时在 5.7 配置中禁用
ONLY_FULL_GROUP_BY，但不可长期保留 -
STRICT_TRANS_TABLES会拒绝插入含零日期（'0000-00-00'）或超长字符串的记录，需提前清洗数据或调整字段长度 - 5.7 默认认证插件变为
mysql_native_password，旧客户端连接可能失败，需在 5.7 启动配置中显式设置default_authentication_plugin=mysql_native_password
真正麻烦的不是步骤本身，而是每个环节都依赖前序环节的干净收尾：5.5 到 5.6 没跑通 mysql_upgrade，5.6 到 5.7 就根本启不动；5.6 里没清理掉 NO_ZERO_DATE，5.7 启动日志就会卡在元数据校验。线上升级务必在从库先行验证，且每步完成后保留可回退的逻辑备份（mysqldump 输出），别信“只改个配置就能切”的说法。
