MY-010929错误表明MySQL 8.0启动时检测到mysql库中存在MyISAM系统表（如mysql.user、mysql.db），因MyISAM不支持事务、原子DDL及数据字典一致性，服务强制终止初始化。
MY-010929 错误说明系统表引擎不合法
MySQL 8.0 启动时若检测到 mysql 库中仍有 MyISAM 表（如 mysql.user、mysql.db），会直接报错 MY-010929 并终止初始化，不是警告，是硬性拦截。这不是配置问题，而是数据字典架构强制要求：所有系统表必须为 InnoDB。
InnoDB 是数据字典一致性的唯一支撑
MySQL 8.0 彻底废弃 .frm 文件，元数据统一存入 InnoDB 系统表。这要求：
- DDL 操作必须原子执行（成功则全生效，失败则全回滚）
- 表结构变更需与数据变更在同一个事务中提交
- 崩溃后能通过
redo log精确恢复元数据状态
MyISAM 不支持事务、无 undo log、崩溃后状态不可预测，根本无法参与这套机制。哪怕只有一张系统表是 MyISAM，mysqld 就会在启动阶段卡死。
权限操作依赖事务，MyISAM 做不到原子性
GRANT、CREATE ROLE、动态权限等操作，本质是一组 DCL 语句。例如：
GRANT SELECT ON db.* TO 'u'@'%';<br>GRANT INSERT ON db.* TO 'u'@'%';
若中途崩溃，MyISAM 可能只写入一条权限记录，造成权限撕裂；而 InnoDB 通过 undo log 和 redo log 保证整组操作要么全生效、要么全回滚。你查 information_schema.role_table_grants 得到的结果，背后就是事务一致的快照。
主从复制和高可用链路彻底失效
MySQL 8.0 默认 binlog_format=ROW，但 MyISAM 不支持行格式日志，实际退化为 STATEMENT 模式，导致 NOW()、UUID() 等函数在主从生成不同值。更严重的是：
- 高可用工具（如 Orchestrator、MHA）依赖
performance_schema.replication_applier_status_by_coordinator判断同步位点，而这些表本身是 InnoDB —— 若权限表仍是 MyISAM，元数据层已不统一 - 集群自动故障转移时，新主库启动若检测到
mysql库含 MyISAM 表，部分 8.0.33+ 版本会直接拒绝加载，报错ER_UNKNOWN_STORAGE_ENGINE
真正难排查的，是那些没报错但后续行为异常的情况：比如转换中途被中断，mysql 库下部分表变成 InnoDB、部分仍是 MyISAM，此时服务可能“看似启动成功”，但执行 CREATE USER 或权限相关操作时随机失败。
