mysql 8.0 中 myisam 已被官方正式弃用（deprecated），系统表全量迁移至 innodb，禁用后实例正常运行；启用 disabled_storage_engines=myisam 可硬性拦截建表请求，报错 error 3161，但 show engines 显示残留需以实际建表失败为准。
MySQL 8.0 中 MyISAM 已被官方标记为 deprecated
不是“不推荐”，而是 MySQL 官方在 8.0+ 手册里只把 MyISAM 放在 Deprecated Features 和 Compatibility Notes 章节，不再提供独立运维指南。SHOW ENGINES 输出中 MyISAM 的 Comment 字段明确写着 deprecated, not encouraged——这是硬性信号，不是建议语气。
你查 information_schema.TABLES 或执行 mysql_upgrade，工具从 8.0.33 起默认跳过 MyISAM 表检查；mysqlcheck --repair 对它的修复成功率显著下降。这不是“还能凑合用”，是“不再保”。
MyISAM 在 MySQL 8.0 高可用链路上彻底失效
所有主流高可用方案（InnoDB Cluster、MHA、Orchestrator）依赖三个前提：事务一致性、崩溃可恢复性、binlog 精确重放。而 MyISAM 全部不满足：
- 主库异常宕机后，从库提升为主库时，
MyISAM表大概率报Table is marked as crashed或Got error 127 from storage engine，且REPAIR TABLE在 8.0+ 中已被弱化，无法安全修复 - MySQL 8.0 默认
binlog_format=ROW，但MyISAM不支持行格式日志，实际退化为STATEMENT模式，导致NOW()、UUID()等函数在主从产生不同值 - 集群自动故障转移时，新主库启动若检测到
mysql库含MyISAM表，部分 8.0.33+ 版本会直接拒绝加载，报错ER_UNKNOWN_STORAGE_ENGINE
系统表强制 InnoDB 化，说明 MyISAM 已无容身之地
MySQL 8.0 所有系统表（mysql.user、mysql.db、mysql.tables_priv 等）全部切换为 InnoDB，根本原因不是“更好”，而是“不换就崩”：
-
mysqld崩溃后，MyISAM系统表极易损坏，REPAIR TABLE失败率高，连SELECT USER()都可能失败，实例直接失去访问控制 - 权限变更（如
GRANT、角色创建）需事务原子性，MyISAM无法保证多条 DCL 语句要么全生效、要么全回滚；而InnoDB通过undo log和redo log实现强一致 - 哪怕
mysql.user只有几百行，“小表不用动”是最大误区：它是启动时最先加载、最后释放的系统表，引擎不一致会触发元数据校验链路中断，卡在Waiting for table metadata lock
禁用 MyISAM 引擎已成生产环境事实标准
从 MySQL 5.7.8 起，disabled_storage_engines=MyISAM 参数即可硬性拦截所有 MyISAM 建表请求，8.0+ 系统表全量 InnoDB 化后，该配置启用后实例照常运行：
- 以下操作会立即报错
ERROR 3161：CREATE TABLE ... ENGINE=MyISAM、ALTER TABLE ... ENGINE=MyISAM、CREATE TEMPORARY TABLE ... ENGINE=MyISAM -
SHOW ENGINES仍显示MyISAM为YES，这是状态展示残留；真判断是否禁用成功，得看建表是否报错 - 老监控脚本或备份工具若硬编码
ENGINE='MyISAM'或解析建表语句不严谨，可能漏匹配或还原出非法语句，这类隐式依赖最难排查
真正该警惕的，不是“怎么禁用”，而是“没意识到自己还在用 MyISAM”。线上只要留一个，下次主从切换或滚动重启，就可能卡在元数据锁上动弹不得。
