mysql 8.0+ 已彻底放弃对 myisam 的高可用与复制场景支持，继续保留 myisam 表等于主动埋下集群失效、主从不一致、切换即宕机的隐患。
MyISAM 在 MySQL 8.0+ 中已失去高可用基础能力
MySQL 高可用方案（如 InnoDB Cluster、MHA、Orchestrator）依赖事务一致性、崩溃可恢复性、binlog 精确重放三大前提。MyISAM 全部不满足：
- 主库异常宕机后，从库提升为主库时，MyISAM 表大概率报
Table is marked as crashed或Got error 127 from storage engine -
SHOW TABLE STATUS的Comment字段显示Crashed，但无法用REPAIR TABLE安全修复（MySQL 8.0+ 已弱化 MyISAM 修复逻辑） - MySQL 8.0 默认
binlog_format=ROW，而 MyISAM 不支持行格式日志，实际退化为STATEMENT模式，导致 NOW()、UUID() 等函数在主从产生不同值
MySQL 官方已停止维护 MyISAM 的关键路径
不是“还能用”，而是“不再保”。几个明确信号：
- MySQL 8.0 移除了
query_cache，而 MyISAM 是其唯一受益引擎；该功能移除后，MyISAM 唯一性能优势消失 - MySQL 8.0.33+ 开始，
mysql_upgrade工具默认跳过 MyISAM 表检查，mysqlcheck --repair对 MyISAM 的修复成功率显著下降 - 官方文档中，“MyISAM”关键词在 8.0+ 版本手册里仅出现在“Deprecated Features”和“Compatibility Notes”章节，不再有独立运维指南
未来版本可能直接拒绝加载 MyISAM 表
这不是猜测，而是已有技术铺垫：
- MySQL 8.4（开发中）已引入
storage_engine_blacklist配置项，可显式禁用指定引擎；虽未默认启用，但机制已存在 - InnoDB Cluster 的
group_replication_require_row_format=ON强制要求所有表支持 ROW 格式日志，MyISAM 被自动排除在集群节点之外 - 云厂商 RDS 服务（如阿里云 PolarDB、腾讯云 CynosDB）已在后台 silently 将 MyISAM 表转为 InnoDB，且不通知用户——说明兼容层维护成本已高于转换成本
真正卡住升级节奏的，从来不是迁移动作本身，而是那些散落在触发器 definer、备份脚本中的 ENGINE=MyISAM 硬编码，以及开发人员对“只读小表不用动”的惯性认知。一旦某次主从切换或集群扩缩容触发底层引擎校验失败，修复窗口往往只有分钟级。
