MySQL 8.0中MyISAM已被完全弃用：系统表强制使用InnoDB并由事务性数据字典管理；业务表若存在MyISAM，升级后虽可能暂启，但会触发ERROR级报错，极易导致启动失败或权限异常。
MyISAM表在MySQL 8.0中已被完全弃用
MySQL 8.0 不再支持 MyISAM 作为系统表引擎，所有 mysql 系统库表（如 user、plugin、proc）都强制使用 InnoDB，并由事务性数据字典管理。业务库中若存在 MyISAM 表，升级后虽可能暂时“能启动”，但会直接触发 util.checkForServerUpgrade() 的 ERROR 级别报错，且后续极大概率导致 mysqld 启动失败或权限校验异常。
检查 MyISAM 表的准确命令和常见误判点
别只查 information_schema.TABLES 就以为完事——有些表看似是 MyISAM，实为 MEMORY 或其他引擎；有些旧备份还原后残留的临时表也会干扰判断。必须用以下组合确认：
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE = 'MyISAM' AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys');- 额外补查
SHOW ENGINES;确认 MyISAM 引擎是否仍被编译启用（8.0 默认禁用，但某些自定义编译版本可能保留） - 注意：
mysql.proc在 5.7 是 MyISAM，但在 8.0 已移除，不是“可转换”而是“必须删除/重写”
转换 MyISAM 表时容易踩的坑
单纯执行 ALTER TABLE t ENGINE=InnoDB; 并不总是安全，尤其对大表或含全文索引、分区、外键依赖的场景：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 全文索引需重建：
MyISAM的全文索引语法与InnoDB不兼容，转换后要手动ALTER TABLE ... DROP FULLTEXT INDEX再重建 - 分区表限制：MySQL 8.0 要求分区表必须为 InnoDB，但非原生分区（如 MyISAM 分区）无法直接转换，得先去分区再转引擎
- 锁表现象：
ALTER TABLE ... ENGINE=InnoDB在 5.7 下是阻塞操作，生产环境务必加--single-transaction配合 mysqldump 导出再重建，避免长事务阻塞 - 自增字段行为差异：MyISAM 的自增值在重启后不持久，InnoDB 持久化，转换后应用若依赖“重启重置 ID”，逻辑会出错
为什么不能等到升级后再处理 MyISAM？
因为 mysqld --upgrade=FORCE 不会帮你转业务表，它只处理系统库元数据。一旦启动时检测到 MyISAM 表，8.0 会直接拒绝加载对应库，错误日志里出现 Unknown storage engine 'MyISAM' 或 Table 'xxx' is read only ——这不是配置问题，是引擎不可用。更麻烦的是，部分云厂商控制台的“一键升级”会跳过这个检查，结果实例起来但业务连不上任何 MyISAM 表，排查时才发现是引擎层面被静默禁用。
