MySQL 8.0 MGR 集群强制要求使用 InnoDB 引擎，直接拒绝 MyISAM 表的创建或修改操作，因其不满足 Paxos 共识所需的事务日志、一致重放和精确回滚等核心要求。
MySQL 8.0 MGR 集群拒绝 MyISAM 表的直接表现
执行 CREATE TABLE t1 (...) ENGINE=MyISAM 或 ALTER TABLE t1 ENGINE=MyISAM 在已加入 MGR 的节点上会立即报错：ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin。这不是警告，而是硬拦截 —— MGR 插件在 DDL 解析阶段就拒绝了非事务引擎的元数据变更。
MGR 强制 InnoDB 的底层逻辑是共识协议本身
MGR 基于改良 Paxos 实现多数派写入确认，它要求每个事务提交前必须满足：所有节点对同一事务的 binlog event 解析结果完全一致、崩溃后能按相同顺序重放、回滚时能精确撤销已部分应用的操作。MyISAM 完全不满足这三点：
- 无事务日志，
binlog_format=ROW下无法生成行变更事件，只能退化为STATEMENT，导致NOW()、UUID()等函数在主从产生不同值 - 崩溃后 MyISAM 表状态不可预测，
REPAIR TABLE在 MySQL 8.0+ 中已被弱化，SHOW TABLE STATUS显示Comment: Crashed但修复失败率极高 - 没有 MVCC 和 undo log，MGR 无法实现“事务可见性同步”，节点间快照不一致会导致读取到中间态脏数据
跳过校验或强行启用 MyISAM 的后果是集群级失效
有人尝试设 skip_myisam=OFF 并重启节点，以为能绕过限制 —— 这在 MySQL 8.0.33+ 已无效。即使临时生效，只要该节点参与组复制，以下问题必然发生：
- 主节点写入 MyISAM 表后，从节点在 apply binlog 时因引擎不兼容直接中断复制，报
Slave SQL thread retried transaction后永久挂起 - 集群健康检测将该节点标记为
UNREACHABLE，多数派投票失败，整个集群进入只读冻结状态 - 执行
SELECT * FROM performance_schema.replication_group_members可见该节点状态卡在RECOVERING，但实际无法恢复
真正需要关注的是存量 MyISAM 表迁移路径
线上还有 MyISAM 表？别用 ALTER TABLE ... ENGINE=InnoDB 直接硬切。重点检查三件事：
- 确认表是否含全文索引：
SHOW CREATE TABLE t1查看是否有FULLTEXT KEY—— MySQL 8.0.16+ 已移除 MyISAM 全文索引支持，迁移到 InnoDB 后需重建为IN NATURAL LANGUAGE MODE或改用外部搜索引擎 - 检查
AUTO_INCREMENT列是否被用作业务唯一标识：InnoDB 的自增锁机制与 MyISAM 不同，高并发插入可能暴露间隙，需评估业务容忍度 - 观察
information_schema.TABLES中DATA_LENGTH + INDEX_LENGTH是否远超innodb_buffer_pool_size：大 MyISAM 表转 InnoDB 后首次加载会引发大量磁盘 IO，建议在低峰期分批执行
最易被忽略的一点：MGR 不拒绝「已有」MyISAM 表，只拒绝「新建/修改」动作。但只要该表被任何节点写入，集群就会在下一次心跳检测中触发一致性校验并强制驱逐节点 —— 这个时间窗口往往只有几十秒。
