mysql 8.0 彻底废弃 myisam 引擎对系统表的支持，因其不满足事务安全、崩溃可恢复和元数据强一致要求；启动时校验失败即退出，mysql_upgrade 已废弃，数据字典强制使用 innodb。
MySQL 8.0 不是“移除 MyISAM 格式”，而是彻底废弃 MyISAM 引擎对系统表的支持——因为系统表必须事务安全、崩溃可恢复、元数据强一致，而 MyISAM 根本做不到。
MyISAM 系统表在 8.0 启动时直接失败
错误日志里一旦出现 Table 'mysql.user' doesn't exist 或 [MY-010929] Storage engine 'MyISAM' does not support system tables，说明 mysqld 拒绝加载：它在启动初期就校验 mysql 库下所有表的引擎和结构，只要有一张是 MyISAM（比如 mysql.columns_priv），进程立即退出。
- 这不是配置没调好，也不是权限问题，是硬性校验失败
-
mysql_upgrade在 8.0.16+ 已废弃，执行它只会输出mysql_upgrade is deprecated，完全无效 - 5.7 升级上来的实例若未做迁移，
mysql.plugin、mysql.servers这些表大概率还是 MyISAM，8.0 启动时根本不会尝试读取它们
数据字典重构要求引擎必须支持事务
8.0 把原来散落在 .frm、.opt、.TRG 等文件里的元数据，全部收进 InnoDB 表（如 mysql.global_grants、mysql.role_edges），并统一存到 mysql.ibd 中。这套机制依赖：
- InnoDB 的 redo log 和 undo log：保证 DDL 原子性，比如
ALTER TABLE中途宕机也能回滚 - 崩溃恢复能力：mysqld 重启后能自动修复元数据不一致，而 MyISAM 的
.MYI/.MYD文件损坏后，REPAIR TABLE在 8.0+ 中已大幅弱化，成功率极低 - 权限变更的原子性：
GRANT和REVOKE必须要么全生效、要么全失败；MyISAM 无法提供事务边界，旧版曾频繁出现“权限写入磁盘但未生效”的中间态
高可用与复制链路彻底不兼容 MyISAM
主流集群方案（InnoDB Cluster、MHA、Orchestrator）全部基于三个前提，MyISAM 全部不满足：
- binlog_format=ROW 是 8.0 默认，但 MyISAM 不支持行格式日志，被迫退化为 STATEMENT 模式，导致
NOW()、UUID()主从结果不一致 - 主库异常宕机后，从库提升为主库时，MyISAM 表常报
Table is marked as crashed或Got error 127 from storage engine，且无法安全修复 - 故障转移过程中，新主库启动会再次校验
mysql库引擎，8.0.33+ 版本遇到 MyISAM 表直接拒绝加载，报错ER_UNKNOWN_STORAGE_ENGINE
真正关键的不是“能不能用”，而是“出问题时有没有兜底”。MyISAM 系统表在 8.0 里没有崩溃恢复路径、没有原子操作保障、没有复制一致性基础——留它，等于在数据库心脏位置埋雷。
