查MyISAM表必须用information_schema.TABLES全局扫描，因SHOW TABLE STATUS仅限当前库且视图返回Engine=NULL；需过滤系统库并结合TABLE_ROWS与DATA_LENGTH识别高风险大表。
查 MyISAM 表不能只靠 SHOW TABLE STATUS
它只显示当前数据库（USE 后的库），漏掉系统库和其它业务库；且对视图返回 Engine=NULL，容易误判为“无 MyISAM”。真正要摸清全貌，得用 information_schema.TABLES 全局扫描：
- 查所有非系统库的 MyISAM 表：
SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_ROWS, DATA_LENGTH FROM information_schema.TABLES WHERE ENGINE = 'MyISAM' AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys'); - 必须加
TABLE_SCHEMA NOT IN排除系统库——否则会把mysql库里本该是 InnoDB 的残留表也扫出来，干扰判断 -
TABLE_ROWS是估算值，但结合DATA_LENGTH能快速识别大表（比如 >1GB）是否还在用 MyISAM，这类表迁移风险最高
为什么 mysql 库里还有 MyISAM 表？
这不是配置遗漏，而是 MySQL 8.0 启动升级流程静默失败的典型表现。MY-010929 错误虽已消失，但部分系统表仍卡在 MyISAM 状态，常见于：手动执行过 ALTER TABLE mysql.event ENGINE=InnoDB 却中途失败、mysqld --upgrade=FORCE 运行时 /var/lib/mysql/mysql/ 下残留 .frm 文件、或 SELinux 拦截了元数据写入。
- 确认
mysql库真实状态：SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'mysql' AND ENGINE = 'MyISAM'; - 重点盯
user、db、tables_priv这三张——只要其中一张仍是 MyISAM，CREATE USER或GRANT就可能随机报错，现象是“语法没错却权限不生效” - 别信
mysql_upgrade输出的 “OK”，它在 8.0.16+ 已废弃，对引擎转换零作用
ALTER TABLE ... ENGINE=InnoDB 在系统表上大概率失败
直接跑这个命令，几乎必然触发 ERROR 1067 (42000): Invalid default value for 'modified' 或类似字段定义冲突。因为 MySQL 8.0 系统表字段默认值、NOT NULL 约束、时间类型精度都比旧版严格，MyISAM 表结构没经过校验就硬转，会卡在 DDL 校验阶段。
- 先看具体报错字段：
SHOW CREATE TABLE mysql.event;，检查modified、created、last_accessed等 TIMESTAMP 字段是否含'0000-00-00 00:00:00' - 修复再转：例如
ALTER TABLE mysql.event MODIFY COLUMN `modified` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP; - 注意顺序：必须先
MODIFY COLUMN调整字段定义，再ENGINE=InnoDB，反过来会失败 - 所有系统表都要逐个检查字段，默认值不合法的都得先修，不能批量脚本一跑了之
排查后最易被忽略的点
查完、修完、转完，不代表万事大吉。MySQL 8.0 对系统表一致性极其敏感，哪怕只有一张表转换成功但索引未重建、或 datadir 权限未重置，后续行为就会飘忽不定。
- 检查
innodb_file_per_table是否为ON：如果关着，新转的 InnoDB 表实际还挤在共享表空间里，information_schema可能显示引擎正确，但磁盘文件仍是ibdata1里的碎片 - 确认
datadir下对应库目录里，MyISAM 的.MYD/.MYI文件是否真被删干净——残留文件会让 MySQL 在某些操作中回退到旧路径逻辑 - 重启后立刻验证：
SELECT COUNT(*) FROM mysql.user;和CREATE USER 'test'@'localhost';必须同时成功，才算系统表真正就绪
