mysql 8.0系统表强制使用innodb，根本原因是myisam崩溃后无法保证权限数据一致性，导致实例失去访问控制；权限变更需事务原子性，myisam不支持；主从复制下因row格式不兼容而失效；官方已弃用其运维保障。
崩溃恢复不可妥协，不是“更好”，而是“不换就崩”
MySQL 8.0 所有系统表（mysql.user、mysql.db、mysql.tables_priv 等）强制使用 InnoDB，根本原因不是性能提升或功能增强，而是 MyISAM 在异常宕机后大概率导致权限数据损坏，进而使整个实例失去访问控制能力。一旦 mysqld crash，MyISAM 系统表常报 Table is marked as crashed；而 MySQL 8.0+ 中 REPAIR TABLE 已被弱化，修复成功率极低——此时连 SELECT USER() 都可能失败。
权限变更必须原子执行，MyISAM 做不到事务级 DCL
MySQL 8.0 引入角色（CREATE ROLE）、动态权限（如 BACKUP_ADMIN）、密码历史策略等，这些操作天然需要原子性。例如执行：
GRANT SELECT ON db.* TO 'u'@'%';<br>GRANT INSERT ON db.* TO 'u'@'%';
若中途崩溃，MyISAM 可能只写入一条权限记录，造成权限状态撕裂；InnoDB 则通过 undo log 和 redo log 保证整组 DCL 操作要么全生效、要么全回滚。你查 information_schema.role_table_grants 得到的结果，背后就是事务一致的快照。
主从复制下 MyISAM 权限表直接失效
MySQL 8.0 默认 binlog_format=ROW，但 MyISAM 不支持行格式日志，实际退化为 STATEMENT 模式，带来两类硬伤：
-
NOW()、UUID()类函数在主从生成不同值，权限表中时间戳或 token 字段主从不一致 - 集群自动故障转移时，新主库启动若发现
mysql库含 MyISAM 表，部分版本（如 8.0.33+）会直接拒绝加载，报ER_UNKNOWN_STORAGE_ENGINE
这不是配置问题，而是元数据层已不统一——权限表是 MySQL 启动时最先加载、最后释放的系统表，任何引擎不一致都会触发校验链路中断。
官方已明确放弃 MyISAM 系统表运维保障
MySQL 8.0+ 手册中，“MyISAM”关键词仅出现在 Deprecated Features 章节；mysql_upgrade 自 8.0.33 起默认跳过 MyISAM 表检查；mysqld --upgrade=FORCE 是唯一能强制完成系统表转换的路径。线上环境只要还留一个 MyISAM 权限表，下次滚动重启或主从切换，就可能卡在 Waiting for table metadata lock 上动弹不得——这不是概率问题，是确定性风险。
