MySQL 5.6 系统表必须保持 MyISAM 引擎，强行改为 InnoDB 会导致启动失败、权限失效或升级失败；唯一安全路径是升级至 MySQL 5.7+，由 mysql_upgrade 自动转换为 InnoDB 并校验一致性。
MySQL 5.6 的系统表（如 mysql 库下的 user、db、tables_priv 等）默认仍是 MyISAM，但官方从 5.7 开始强制使用 InnoDB，5.6 中**不建议、也不支持手动修改系统表引擎**。强行执行 ALTER TABLE mysql.user ENGINE=InnoDB 会导致实例启动失败或权限系统不可用。
为什么不能直接 ALTER SYSTEM TABLES
系统表不是普通业务表：它们被 MySQL Server 内核硬编码依赖，启动时会校验表结构、存储引擎、字符集和索引完整性。5.6 版本的 server 二进制只适配 MyISAM 格式的系统表元数据加载逻辑。一旦改成 InnoDB：
- mysqld 启动时可能报错
Table 'mysql.user' doesn't exist in engine或卡在Initializing Database阶段 -
FLUSH PRIVILEGES失效，新授权不生效 - 部分管理命令（如
CREATE USER）内部调用失败，返回模糊错误ERROR 1820 (HY000): You must SET PASSWORD before executing this statement - 即使侥幸启动，后续升级到 5.7+ 时
mysql_upgrade会拒绝处理，必须重装初始化
MySQL 5.6 中真正可行的“迁移”路径
所谓“迁移到 InnoDB”，在 5.6 语境下只有一条安全路径：**升级到 MySQL 5.7 或更高版本**。5.7 初始化时会自动将所有系统表转为 InnoDB，并重建字典一致性。你无法绕过这个前提。
- 先在测试环境完整执行
mysqld --initialize+mysql_upgrade流程，验证权限、复制、备份恢复是否正常 - 确认应用兼容性：5.7 默认启用
STRICT_TRANS_TABLES，旧 SQL 可能报错；password字段名已改为authentication_string - 不要尝试导出
mysql库再导入——mysqldump --databases mysql生成的 SQL 不含 CREATE DATABASE 语句，且 INSERT 会因 AUTO_INCREMENT 和触发器冲突失败 - 物理迁移（xtrabackup）也不行：5.6 的
mysql表空间无法被 5.7 实例 IMPORT，报错Tablespace is missing for table mysql/user
升级前必须做的三件事
跳过这三步，90% 的升级会在权限或复制环节翻车：
- 执行
SELECT user,host,plugin FROM mysql.user;，确认所有账号 plugin 是mysql_native_password（5.7 默认用caching_sha2_password，老客户端连不上） - 关闭 GTID（如果用了）：
SET GLOBAL gtid_mode=OFF_PERMISSIVE;，否则mysql_upgrade会拒绝运行 - 备份原始
mysql目录（如/var/lib/mysql/mysql/下所有 .MYD/.MYI 文件），升级失败时可回退到 5.6 并重置 root 密码
系统表引擎不是配置项，而是版本契约。想用 InnoDB 系统表，唯一办法是升级——没有“安全绕过”的技巧，任何试图 patch 系统表结构的操作，本质都是在赌 MySQL 内核没做校验，而 5.6 已经做了。
