MY-010929错误是MySQL 8.0启动时因系统表仍为MyISAM引擎而强制终止初始化的硬性拦截，根源在于MyISAM不支持事务、undo log及原子DDL，无法满足数据字典一致性要求；mysql_upgrade已失效，必须用mysqld --upgrade=FORCE手动触发InnoDB转换，否则服务虽“看似启动成功”，但权限操作会随机失败。
MY-010929错误不是配置问题，是启动校验失败的硬性拦截
MySQL 8.0 启动时发现 mysql.user、mysql.db 等系统表仍是 MyISAM 引擎，会直接报 [MY-010929] Storage engine 'MyISAM' does not support system tables 并终止初始化——这不是警告，是服务拒绝加载的明确信号。
原因很直接：MyISAM 不支持事务、无 undo log、崩溃后元数据状态不可预测，根本无法满足 MySQL 8.0 的原子 DDL 和统一数据字典要求。哪怕只有一张系统表没转成功，整个实例就卡住。
- DDL 必须原子执行（全成功或全回滚），MyISAM 做不到
- 表结构变更需与数据变更在同一个事务中提交，MyISAM 无事务上下文
- 崩溃恢复依赖 redo log 精确重建元数据，MyISAM 没有这套机制
mysql_upgrade 在 8.0 中已失效，别再运行它
从 MySQL 8.0.16 起，mysql_upgrade 已被标记为 deprecated，它不再触发任何系统表引擎转换逻辑。你看到的 “mysql_upgrade is deprecated” 不是提醒，是明确告知：这条命令对系统表迁移零作用。
真正起效的是 mysqld 启动时的内建升级流程，但它只在首次用 8.0+ 二进制启动旧数据目录时尝试自动转换，且极易静默跳过——不报错、不中断、也不完成转换。
- 自动流程失败后，服务可能“看似启动成功”，但执行
CREATE USER或权限操作时随机失败 - 日志里没有 ERROR 不代表成功，要看是否有
mysql.user table upgraded to InnoDB这类明确记录 - 一旦错过首次启动窗口，后续常规启动不会再重试转换
强制转换必须用 mysqld --upgrade=FORCE
唯一可靠路径是手动触发完整升级流程：mysqld --user=mysql --datadir=/var/lib/mysql --upgrade=FORCE。这不是可选步骤，是必须执行的显式指令。
关键细节常被忽略：
- 必须先停服务：
sudo systemctl stop mysql - 必须用绝对路径调用新版本
mysqld，不能依赖 PATH - 进程必须自然退出（不能加
&），否则转换中途终止 - 失败主因通常是三件事：SELinux 权限未重置（
restorecon -R /var/lib/mysql）、残留/var/lib/mysql/mysql/*.frm干扰解析、tmpdir或datadir分区空间不足
disabled_storage_engines=MyISAM 是禁用后的安全兜底
系统表完成 InnoDB 化后，可通过配置 disabled_storage_engines = MyISAM 彻底堵死新建 MyISAM 表的可能。这不是预防措施，而是确认转换完成后的加固动作。
设置后以下语句会立即报错 ERROR 3161：
CREATE TABLE t ENGINE=MyISAMALTER TABLE t ENGINE=MyISAMCREATE TEMPORARY TABLE tmp ENGINE=MyISAM
注意：SHOW ENGINES 里 MyISAM 仍显示 YES，这是状态展示残留；判断是否生效，只看建表是否报错。
真正难排查的，是那些没报错但行为异常的情况：比如存储过程里 CREATE TEMPORARY TABLE 没指定 ENGINE，旧环境默认 MyISAM，新环境默认 InnoDB，事务行为差异导致中间状态不一致——这种必须结合业务逻辑回归验证。
