MySQL 8.0强制使用InnoDB是因为MyISAM崩溃后无法保证权限数据一致性、不支持事务导致权限状态撕裂、主从复制下因ROW格式日志不兼容而失效，且已被官方彻底弃用。
InnoDB 是 MySQL 8.0 唯一能撑住系统启动、权限变更和主从切换的引擎，不是“更优”，而是“不选它就起不来”。
MySQL 8.0 启动失败常因 mysql.user 表崩溃，根源是 MyISAM 已被踢出系统表支持
MySQL 8.0 启动时最先加载 mysql.user、mysql.db 等系统表。如果这些表还是 MyISAM，mysqld crash 后大概率报 Table is marked as crashed；而 REPAIR TABLE 在 8.0+ 中已弱化，修复成功率极低——此时连 SELECT USER() 都可能失败，整个实例失去访问控制能力。
- 所有系统表（包括
mysql.role_edges、mysql.procs_priv）在 8.0+ 全部强制为 InnoDB，不可配置回退 -
mysql_upgrade自 8.0.33 起默认跳过 MyISAM 表检查，官方已明确放弃保障 - 集群自动故障转移时，若检测到
mysql库含 MyISAM 表，部分版本（如 8.0.33+）会直接拒绝加载，报错ER_UNKNOWN_STORAGE_ENGINE
GRANT/REVOKE 必须原子执行，MyISAM 不支持事务导致权限状态撕裂
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返回的结果，背后依赖的是事务一致的快照，这只有 InnoDB 能提供 - MyISAM 的
FLUSH PRIVILEGES是粗粒度重载，无法应对并发修改场景 - 任何涉及
SET DEFAULT ROLE或REVOKE多权限的操作，都隐式要求事务边界
主从复制下 MyISAM 权限表直接失效，ROW 格式日志无法兼容
MySQL 8.0 默认 binlog_format=ROW，但 MyISAM 不支持行格式日志，实际退化为 STATEMENT 模式，引发一系列不一致问题：
-
NOW()、UUID()等函数在主从生成不同值，导致权限表中时间戳或 token 字段主从不一致 - 主从元数据层割裂：
SHOW SLAVE STATUS依赖的系统表本身是 InnoDB，若权限表仍是 MyISAM，校验链路中断 - 某些高可用组件（如 MHA、Orchestrator）在判断同步位点时，会因引擎不统一返回错误或卡死
临时表落盘后必须用 InnoDB，否则崩溃恢复无保障
MySQL 8.0.16+ 内隐临时表（优化器自动创建的）默认走 TempTable 引擎，内存阶段受 temptable_max_ram 限制；超限时按页落盘，而非整表 dump —— 这个磁盘承接引擎由 internal_tmp_disk_storage_engine 控制，默认就是 InnoDB。
- 选择 InnoDB 不是因为它快，而是因为它复用已有的缓冲池、
redo log机制和崩溃恢复流程 - MyISAM 作为磁盘临时表引擎，在异常宕机后无法保证落盘临时表数据一致性，可能导致后续查询结果错误
-
internal_tmp_disk_storage_engine设为MyISAM在 8.0+ 会静默忽略，实际仍用 InnoDB
真正容易被忽略的，不是“该不该用 InnoDB”，而是：只要线上环境还残留一个 MyISAM 系统表，下次滚动重启或主从切换，就可能卡在 Waiting for table metadata lock 上动弹不得——这不是性能问题，是启动链路的单点故障。
