MySQL 8.0启动时检测到mysql.user或mysql.db等任一系统表为MyISAM即报MY-010929并终止初始化，因MyISAM不支持事务、undo/redo log，无法满足数据字典原子性与崩溃一致性要求，且mysql_upgrade已弃用，必须用mysqld --upgrade=FORCE强制转换。
MySQL 8.0 启动时只要检测到 mysql.user、mysql.db 等任一系统表仍是 MyISAM，就会直接报 MY-010929 并终止初始化——这不是配置没调对，是内核级硬性拦截，连错误日志都可能写不全。
MY-010929 报错说明服务根本没启动成功
这个错误不是“警告”或“建议”，而是 MySQL 8.0 启动流程中数据字典初始化阶段的强制校验失败。它发生在 mysqld 进程刚加载完配置、还没开始监听端口之前。常见现象包括：
- 执行
systemctl start mysql后立即退出，状态显示failed -
journalctl -u mysql或错误日志里只看到一行MY-010929，后面没其他日志 - 尝试连接时提示
Can't connect to local MySQL server，但进程已不存在
根本原因：MySQL 8.0 的数据字典（data dictionary）完全基于 InnoDB 实现，所有元数据（用户、权限、角色、存储过程定义等）必须存于事务型引擎中。MyISAM 不支持事务、无 undo/redo log、崩溃后状态不可预测，无法满足原子 DDL 和崩溃一致性要求。
mysql_upgrade 已失效，别再依赖它
从 MySQL 8.0.16 起，mysql_upgrade 工具被标记为 deprecated；8.0.33+ 版本默认跳过 MyISAM 表检查。它不再触发任何系统表引擎转换逻辑。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 运行
mysql_upgrade后查SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='mysql' AND TABLE_NAME='user';，结果仍为MyISAM—— 这很正常，不是你操作错了 - 真正起作用的是 mysqld 自身的升级机制，但必须显式触发：
mysqld --upgrade=FORCE - 该命令仅在首次用 8.0+ 二进制启动旧数据目录时有效，且必须由 8.0 的
mysqld执行（路径不能错，Docker 用户尤其注意镜像内二进制版本）
部分表转 InnoDB 后“看似能启动”更危险
最麻烦的情况不是直接报错，而是 --upgrade=FORCE 中断或失败后，mysql 库下部分表变成 InnoDB、部分仍是 MyISAM。此时 mysqld 可能“成功启动”，但后续行为异常：
-
CREATE USER随机失败，报Table 'mysql.global_grants' doesn't exist -
SHOW GRANTS FOR 'u'@'%'返回空，但SELECT * FROM mysql.user能查出记录 - 主从复制中断，新主库启动时报
ER_UNKNOWN_STORAGE_ENGINE
这是因为 MySQL 8.0 的权限模型已重构：原 mysql.user 表功能被拆分到 mysql.global_grants、mysql.role_edges、mysql.default_roles 等多张 InnoDB 表。残留 MyISAM 表会破坏元数据层统一性，导致查询路径错乱。
真正难处理的，是那些没有立刻报错、却在关键操作（如创建用户、赋权、故障转移）时才暴露的问题。修复必须停服务、确认磁盘空间和权限、用正确路径的 8.0 mysqld 重跑 --upgrade=FORCE，且要检查日志中是否出现 mysql.user table upgraded to InnoDB 和 Upgrading system tables for new version 这类明确成功标识。
