mysqlcheck不用于mysql 5.7→8.0升级兼容性检查，仅校验当前版本下表的物理结构完整性（如innodb页损坏、索引断裂），不检测引擎禁用、语法变更、sql_mode、字符集或保留字等语义级兼容问题。
mysqlcheck 不用于验证 MySQL 升级过程中的“引擎兼容性”，它压根不检查引擎是否能在目标版本中工作。
它只做一件事：确认当前表在**当前版本**下物理结构是否完好。比如 InnoDB 页有没有损坏、索引树是否断裂、MyISAM 的 .MYI 文件校验和是否匹配。它不会告诉你 MyISAM 表在 MySQL 8.0 启动时会不会直接拒载——而这个才是你真正该担心的“引擎兼容性”问题。
mysqlcheck 能查什么？实际能用在哪一步？
它是升级前最后一道“数据健康扫描”，不是兼容性扫描器：
- 运行
mysqlcheck -u root -p --all-databases --check --extended可发现error或warning行，例如MyTable is marked as crashed - 若输出含
MyISAM表报错，必须先修复（mysqlcheck --repair）或转成InnoDB，否则 8.0 启动会失败 - 跳过系统库可用
--ignore-database=mysql --ignore-database=information_schema，但sys库建议保留——它在 8.0 中是视图集合，结构变化大，提前看它是否能正常查询，比盲目忽略更有价值 - 它不识别
TYPE=MyISAM这种已废弃语法，也不会警告你 “这个引擎在 8.0 默认被禁用”
为什么 MyISAM 表在 8.0 启动时会失败？
MySQL 8.0 默认禁用 MyISAM 引擎（skip_myisam=ON），且不再加载其系统表。这不是 mysqlcheck 能感知的问题，而是配置+引擎策略层面的变更：
- 启动 mysqld 时若检测到
mysql.plugin或mysql.servers等 MyISAM 系统表，会直接报错退出 - 即使你手动启用
myisam_recover_options，也无法绕过 8.0 对 MyISAM 元数据的拒绝逻辑 - 真正解法只有两个：
DROP TABLE所有 MyISAM 表，或用ALTER TABLE t ENGINE=InnoDB全量转换（注意：大表需评估锁和空间）
那该用什么查引擎/语法/配置兼容性？
别让 mysqlcheck 越界干活。以下才是正解：
- 查引擎、字符集、保留字、sql_mode 等真实兼容风险 → 用
mysqlsh的util.checkForServerUpgrade()，它是 Oracle 官方唯一推荐工具 - 查 SQL 执行行为差异（比如 GROUP BY 报错、窗口函数不可用）→ 用
pt-upgrade回放慢日志，在 5.7 和 8.0 上并行执行对比结果 - 查配置项是否已被移除（如
query_cache_type、explicit_defaults_for_timestamp）→ 直接 grep 你的my.cnf，对照 MySQL 8.0 官方文档的 “Removed Options and Variables” 章节
mysqlcheck 的“无报错”误当作“可安全升级”，结果一启 8.0 就卡在 Starting MySQL...。它只保你数据没坏，不保你语法、引擎、配置、认证插件能活。这四类问题，一个都得靠别的工具或人工核对。
