MySQL 8.0+ 系统表强制使用 InnoDB，MyISAM 因不支持事务、崩溃恢复弱、主从复制不兼容、权限操作不原子等问题已彻底弃用，不用则实例无法启动、权限失控、同步失败。
因为 MySQL 8.0+ 系统表已全部强制 InnoDB，且 MyISAM 在事务、崩溃恢复、主从复制、权限一致性等关键环节完全失效——不是“推荐用”，而是“不用就起不来、跑不稳、同步不了”。
MySQL 8.0 启动失败常因 mysql.user 表仍是 MyISAM
MySQL 8.0 启动时最先加载 mysql.user、mysql.db 等系统表。如果这些表还是 MyISAM，mysqld 崩溃后大概率报错：Table is marked as crashed；而 REPAIR TABLE 在 8.0+ 中已弱化，修复成功率极低——此时连 SELECT USER() 都可能失败，整个实例失去访问控制能力。
-
mysql_upgrade自 8.0.33 起默认跳过 MyISAM 表检查，官方已明确放弃保障 - 集群自动故障转移时，若检测到
mysql库含 MyISAM 表，部分版本（如 8.0.33+）会直接拒绝加载，报错：ER_UNKNOWN_STORAGE_ENGINE - 所有系统表（包括
mysql.role_edges、mysql.procs_priv）在 8.0+ 全部强制为 InnoDB，不可配置回退
GRANT/REVOKE 操作必须原子执行，MyISAM 不支持事务导致权限状态撕裂
MySQL 8.0 引入角色（CREATE ROLE）、动态权限（如 BACKUP_ADMIN）、密码历史策略等，这些操作天然需要事务保证。例如执行：
GRANT SELECT ON db.* TO 'u'@'%'; 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 的 WAL 与 MVCC 机制
分布式架构（如 MGR、ShardingSphere 分片集群）中，事务协调器必须依赖底层引擎对 BEGIN、COMMIT、ROLLBACK 和崩溃后 undo log 回滚的精确实现。MyISAM 不支持事务，连 START TRANSACTION 都只是静默忽略——一旦某个节点用 MyISAM 表参与分布式写入，整个事务链路就失去原子性保障。
- MyISAM 表在高并发写入时，表锁争用会使 QPS 骤降 50% 以上；InnoDB 虽有
redo log刷盘开销，但通过组提交（innodb_log_group_commit）可大幅缓解 - InnoDB 的 WAL（Write-Ahead Logging）机制确保：只要
redo log落盘，即使实例崩溃，重启后也能前滚恢复到断电前最后一致状态；MyISAM 仅靠.MYD/.MYI文件，崩溃后需运行myisamchk修复，且无法保证修复后数据与其它节点一致 - 关键配置差异：
innodb_flush_log_at_trx_commit=1（默认）、sync_binlog=1必须启用；innodb_doublewrite=OFF禁用虽提升写入速度，但磁盘部分写失败会导致页损坏
真正决定 InnoDB 是否可靠，从来不是“它支不支持事务”，而是你有没有让它的 redo log、buffer pool、doublewrite 机制在真实负载下持续有效工作——这些细节，比选引擎本身更值得花时间盯住。
