必须经过MySQL 5.6中转，因5.5与5.7存在mysql.user表结构（plugin字段缺失）、InnoDB文件格式（ibdata1不兼容Barracuda）、SQL模式（NO_ZERO_DATE到STRICT_TRANS_TABLES突变）三处底层断裂，跳过将致mysql_upgrade失败、mysqld无法启动或复制中断。
mysql_upgrade 失败、mysqld 启动报错或复制中断——这不是操作技巧问题，而是底层元数据和系统表结构不兼容的硬性限制。
为什么不能跳过 MySQL 5.6 直接升级
5.5 和 5.7 之间存在三处不可绕过的底层断裂点，只有 5.6 能承上启下：
-
mysql.user表在 5.6 新增了plugin字段，5.5 的表结构被 5.7 直接读取时会报Unknown column 'plugin' in 'mysql.user' - InnoDB 文件格式从 5.6 开始强制要求
innodb_file_format = Barracuda，5.5 的ibdata1不被 5.7 启动时接受 - SQL 模式剧变：5.5 默认允许
NO_ZERO_DATE，5.6 开始警告，5.7 默认启用STRICT_TRANS_TABLES和ONLY_FULL_GROUP_BY；跳过 5.6 会让这些模式“突袭”上线，大量旧 SQL 立即失败
5.5 → 5.6 升级时最关键的实操动作
这一步最容易卡死，必须手动干预，否则后续全链路崩坏：
- 用
mysqldump --all-databases --skip-triggers --routines --events > full.sql做逻辑备份；不要物理拷贝ibdata1或data/目录——5.5 的文件无法被 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 - 临时注释掉 5.6 的
my.cnf中STRICT_TRANS_TABLES和ONLY_FULL_GROUP_BY，避免启动即拒绝加载旧表定义
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） -
STRICT_TRANS_TABLES会拒绝插入含零日期（'0000-00-00'）或超长字符串的记录，需提前清洗数据或调整字段长度 - 5.7 默认认证插件变为
mysql_native_password，旧客户端（如 Navicat 旧版、PHPmysql_connect()）可能连不上，需在 5.7 的my.cnf中显式配置default_authentication_plugin=mysql_native_password
Windows 下特别容易踩的坑
路径、服务名、配置文件细节稍有偏差就会启动失败：
-
my.ini中的basedir和datadir必须用正斜杠/或双反斜杠\，单反斜杠会被解析为转义字符，导致路径错误 - 不要复用 5.5 的
my.ini；5.5 中的innodb_additional_mem_pool_size、table_cache等参数在 5.7 已废弃，保留会导致mysqld --initialize报错退出 - 执行
mysqld --initialize前，确保datadir目录为空；若已有文件，会报[ERROR] --initialize specified but the data directory has files in it. Aborting - 升级后首次启动失败，别急着重装——先查 Windows 事件查看器里的
Application日志，90% 的问题是my.ini配置项失效或路径权限不足
