my-010929错误是mysql 8.0彻底禁用myisam系统表的硬性拦截信号，表明mysql.user等系统表仍为myisam引擎，导致服务无法启动；根本原因是myisam不支持事务与原子ddl，而8.0要求元数据变更必须与数据变更在同一事务中提交。
MY-010929错误是MyISAM在8.0里彻底失效的明确信号
MySQL 8.0启动时若检测到任何系统表（如mysql.user、mysql.db）仍是MyISAM引擎，会直接报MY-010929并终止初始化——这不是警告，是硬性拦截。它说明MyISAM已无法参与8.0的数据字典架构，连服务都起不来。
根本原因在于：MyISAM不支持事务、无undo log、崩溃后状态不可预测，而MySQL 8.0要求所有DDL操作必须原子执行（成功则全生效，失败则全回滚），且元数据变更需与数据变更在同一个事务中提交。MyISAM从底层机制上就做不到这点。
- 哪怕只有一张系统表是MyISAM，
mysqld也会卡住不动 -
mysql_upgrade在8.0.16+已废弃，执行它不会触发任何转换逻辑 - 真正有效的只有
mysqld --upgrade=FORCE，且必须配合--datadir和--user显式参数
information_schema查MyISAM表变慢不是配置问题，是内核放弃优化
升级后发现SELECT * FROM information_schema.tables或权限相关查询明显变慢？这不是innodb_buffer_pool_size没调好，而是MySQL 8.0内核已移除对MyISAM元数据访问路径的优化逻辑。
5.7时代大量缓存+跳过校验；8.0默认每次查询都可能触发隐式OPEN TABLE操作，尤其当MyISAM表混在InnoDB库中、数量较多时，开销指数级放大。
-
SET SESSION information_schema_stats_expiry = 86400只能缓解缓存失效频次，不能绕过MyISAM文件锁和打开开销 - 高并发下容易出现
Waiting for table flush或Table is full错误 - 执行
ANALYZE TABLE或REPAIR TABLE仍会阻塞整个连接线程
default-storage-engine配置在8.0里完全失效
你在my.cnf里写了default-storage-engine=MyISAM？MySQL 8.0启动日志会默默打一行警告：[Warning] 'default-storage-engine' is deprecated，然后继续用InnoDB建表——这个配置项已被移除，连解析都不解析。
运行时变量default_storage_engine在8.0中已是只读，SET GLOBAL default_storage_engine = 'MyISAM'会报错：Variable 'default_storage_engine' is a read only variable。
- 新建表不写
ENGINE=，一律走InnoDB，不可更改 - 试图用
mysqld --default-storage-engine=MyISAM启动会失败，提示Unknown suffix 'MyISAM' for variable 'default-storage-engine' - 系统表（如
mysql.user）强制InnoDB，一旦默认引擎被切走，CREATE USER、GRANT等操作会随机失败
InnoDB数据字典让元数据真正具备事务性
MySQL 8.0把mysql.columns、mysql.tables、mysql.indexes这些元数据表全搬到InnoDB里，它们不再是只读定义，而是可被DDL实时修改的事务表。
比如ALTER TABLE t ADD COLUMN c INT，会原子性地插入列记录、更新表定义、补充索引信息——全部打包在一个内部事务中提交。崩溃时靠mysql.innodb_ddl_log（隐藏系统表）反向补偿，保证“坏不了”，而不是“不坏”。
- MyISAM系统表（如旧版
mysql.user）没有undo log，DROP USER中断可能导致权限残留或缺失，且无法自动恢复 - .frm文件在8.0已废弃，表结构和数据统一存于
.ibd，MyISAM依赖的.frm+MYD+MYI三文件模型彻底脱节 - 混合引擎会破坏备份一致性：xtrabackup对MyISAM表需全局锁，而InnoDB可热备，链路一断就全崩
真正难处理的，是那些没报错但后续行为异常的情况：比如--upgrade=FORCE中途被kill，mysql库下部分表转成InnoDB、部分仍是MyISAM，服务看似启动成功，但执行权限操作时才暴露问题。这种半残状态比直接报错更耗排查时间。
