最直接验证MySQL升级后引擎是否生效的方式是查询information_schema.tables中各表实际运行时引擎，而非依赖配置文件或服务状态；需重点检查非系统库的engine字段是否全为预期值（如InnoDB），并逐表比对SHOW CREATE TABLE输出与元数据一致性。
查 information_schema.tables 看实际使用的引擎
升级后最直接的验证方式，不是看配置文件或服务状态，而是查每张表当前生效的引擎。MySQL升级可能触发隐式转换（比如旧版 MyISAM 表在 8.0+ 中被强制转为 InnoDB），但不会自动改写 CREATE TABLE 语句，所以必须以运行时元数据为准。
- 执行：
SELECT table_schema, table_name, engine FROM information_schema.tables WHERE table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys'); - 重点关注
engine字段是否全为预期值（如InnoDB），尤其注意那些历史遗留库里的小表——它们最容易被忽略 - 如果发现混有
MyISAM或MEMORY，别急着删，先确认这些表是否还在被应用读写（有些统计表、日志缓存表确实还依赖MyISAM的表锁特性）
用 SHOW CREATE TABLE 核对建表语句中的 ENGINE 子句
元数据里显示 engine = 'InnoDB'，不代表建表语句里写了它——这关系到后续 DDL 是否可预期。MySQL 升级后，CREATE TABLE t1 (...) 这种不显式声明 ENGINE 的语句，会按 default_storage_engine 设置走；但如果原表是 ENGINE=MyISAM，升级后没重建，SHOW CREATE TABLE 仍会显示 ENGINE=MyISAM，哪怕运行时已转成 InnoDB（仅限某些升级路径）。
- 挑出
information_schema.tables中引擎异常的表，逐个执行：SHOW CREATE TABLE `db_name`.`table_name`;
- 对比输出中
ENGINE=...和information_schema.tables.engine是否一致；不一致说明存在隐式转换或元数据未刷新 - 特别注意：如果
SHOW CREATE TABLE显示ENGINE=InnoDB，但表里有全文索引且升级前是MyISAM，那这个表大概率是“假 InnoDB”——InnoDB的全文索引结构和MyISAM不兼容，查询可能静默失败
检查 default_storage_engine 和 skip-innodb 类配置项
升级后配置文件可能残留旧参数，导致新创建的表默认引擎非预期。比如 MySQL 5.7 升 8.0 后，如果 my.cnf 里还留着 default-storage-engine = MyISAM，或者更隐蔽的 skip-innodb（会让 InnoDB 插件加载失败，进而使 default_storage_engine 回退到 MyISAM），就会埋下隐患。
- 运行：
SELECT @@default_storage_engine, @@have_innodb;
确认返回值是InnoDB和YES - 检查配置文件中是否含
skip-innodb、disabled_storage_engines（8.0.13+ 新参数，若包含InnoDB会导致启动失败）、default-storage-engine（应为InnoDB） -
disabled_storage_engines是容易被忽略的点：它默认为空，但如果升级时用了带该配置的备份模板，可能导致InnoDB被禁用而不报错，只在建表时报Unknown storage engine 'InnoDB'
用 mysqldump --no-data 抽样导出建表语句比对
批量验证时，人工看 SHOW CREATE TABLE 效率低，且无法覆盖所有库。用 mysqldump 导出 DDL 是更贴近真实场景的校验方式——它反映的是 MySQL 当前认可的建表逻辑，包括字符集、行格式、压缩等隐式继承项。
- 命令示例：
mysqldump -d -h127.0.0.1 -uuser -p database_name > schema.sql
（-d即--no-data） - 用
grep -o 'ENGINE=[^ ]*' schema.sql | sort | uniq -c快速统计各引擎出现次数 - 如果导出结果里仍有
ENGINE=MyISAM，但information_schema显示是InnoDB，说明该表处于“DDL 与运行时不一致”状态，后续执行ALTER TABLE ... ENGINE=InnoDB可能触发全表重建，需评估锁和空间影响
实际验证中最容易卡住的，是那些 information_schema.tables.engine 和 SHOW CREATE TABLE 显示不一致的表——它们往往不是配置问题，而是升级过程中部分表元数据损坏或插件加载顺序异常导致的。这种表不能靠重启解决，得用 ALTER TABLE ... FORCE 或导出再导入来重置。
