可以禁用myisam引擎。从mysql 5.7.8起支持disabled_storage_engines=myisam参数，启动时硬性拦截所有myisam建表请求，mysql 8.0系统表已全量迁移至innodb，禁用后实例正常运行。
disabled_storage_engines 是唯一可靠方式，MySQL 8.0+ 中 MyISAM 已被彻底移除系统表依赖，禁用后不会影响启动或初始化。
为什么 disabled_storage_engines = MyISAM 能生效
MySQL 5.7.8 起引入该参数，它在服务启动时硬性拦截所有 MyISAM 表创建请求，包括 CREATE TABLE ... ENGINE=MyISAM 和显式 CREATE TEMPORARY TABLE ... ENGINE=MyISAM；
即使配置了 skip-grant-tables 或降级兼容模式，该限制依然强制生效；
MySQL 8.0 系统表已全量迁至 InnoDB，不再需要 MyISAM 做底层支撑，所以禁用后实例照常运行。
设置后哪些操作会直接报错
以下语句执行时会立即失败，错误码统一为 3161：
CREATE TABLE t1 (...) ENGINE=MyISAMALTER TABLE t2 ENGINE=MyISAMCREATE TEMPORARY TABLE tmp (...) ENGINE=MyISAM- 任何试图将现有表转为 MyISAM 的 DDL
注意：SHOW ENGINES 里 MyISAM 仍显示为 YES（这是状态展示残留），但实际不可用；真正判断是否禁用成功，应以建表报错为准。
升级时 mysql_upgrade 报错怎么办
执行 mysql_upgrade 可能触发 [ERROR] 3161: Storage engine MyISAM is disabled，因为旧版升级脚本可能尝试重建某些历史兼容表；
这不是数据损坏，而是升级流程卡在非必要步骤。解决方法明确：
- 临时注释掉配置文件中的
disabled_storage_engines = MyISAM - 重启 MySQL，再运行
mysql_upgrade - 升级完成后，重新启用该配置并重启
该过程无需停业务太久，且只影响升级窗口期——日常运行中该参数完全静默生效。
禁用后还要小心这些隐式依赖
虽然引擎被禁，但部分遗留逻辑仍可能“假定 MyISAM 存在”：
- 某些监控脚本或 DBA 自定义巡检 SQL 里写了
ENGINE='MyISAM'的硬编码条件，查询information_schema.TABLES时会漏匹配 - 备份工具（如老版本 mysqldump）若加了
--skip-create-options或解析建表语句不严谨，可能在还原时意外拼出 MyISAM 语句 -
myisamchk工具仍可运行，但它对禁用后的实例无实际用途，建议从部署镜像中移除，避免误操作
真正难排查的，是那些没报错、只是结果异常的场景：比如某个存储过程里用 CREATE TEMPORARY TABLE 未指定 ENGINE，而旧环境默认是 MyISAM，新环境默认变成 InnoDB 后，因事务行为差异导致中间状态不一致——这种必须结合业务逻辑回归验证。
