MySQL企业级高可用架构必须依赖InnoDB，因MyISAM在崩溃恢复、主从同步、故障切换、读写分离等环节完全失效：无日志机制致崩溃后需人工修复；不支持事务导致binlog不可信、主从不一致；无MVCC和细粒度锁致读写分离与自动故障转移失败。
MySQL企业级高可用架构必须依赖InnoDB，因为MyISAM等引擎在崩溃恢复、主从同步、故障自动切换、读写分离等关键环节完全失效——不是“不推荐”，而是根本无法参与高可用流程。
崩溃后能否自动恢复？MyISAM会卡死，InnoDB秒级回滚
高可用系统要求节点宕机重启后，数据状态必须可预测、可一致。InnoDB靠redo log和undo log实现前滚+回滚双机制：未提交事务自动丢弃，已提交但未刷盘的变更通过redo log重放补全。MyISAM没有这些日志，崩溃后表文件可能处于crashed状态，必须人工运行myisamchk修复，且修复过程需锁表、无法保证数据与其他节点对齐。
- 云数据库控制台检测到MyISAM表
crashed会直接标记实例为异常，触发自动隔离 -
innodb_force_recovery可分级启动，而MyISAM无任何恢复参数 - 主库崩溃后从库若含MyISAM表，
START SLAVE会报错中断，无法继续同步
主从/集群间能否保持事务一致性？MyISAM让binlog变成“不可信日志”
企业级高可用依赖binlog做逻辑复制、延迟监控、闪回与订阅。但MyISAM表的DML操作不写undo log，也不参与事务边界控制——BEGIN对它无效，ROLLBACK对它无作用，导致binlog中出现“已记录但实际未生效”的语句。当主库执行INSERT INTO t_myisam VALUES(1); ROLLBACK;，这条语句仍会写入binlog并被从库执行，造成主从数据永久不一致。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- MyISAM表无法启用
binlog_format=ROW（报错ERROR 1665 (HY000): Cannot execute statement: binlogging impossible since the storage engine does not support it） - 即使强制用
STATEMENT格式，UPDATE带ORDER BY或LIMIT时主从结果也可能不同 - MGR、ShardingSphere等分布式方案要求所有节点binlog位点严格对应，MyISAM直接破坏该前提
读写分离与自动故障转移为何必然失败？MyISAM锁粒度和事务感知为零
高可用代理（如ProxySQL、RDS内置Proxy）依赖事务状态路由流量：TRX_STATE='ACTIVE'走主库，TRX_STATE='NOT STARTED'才可发往只读节点。MyISAM查询永远被识别为非事务型，全部打向主库；更致命的是，它只有表级锁，一个慢UPDATE会让整张表的SELECT阻塞数分钟，直接拖垮所有只读服务。
- MyISAM的
table_open_cache在连接池高频复用场景下极易耗尽，引发Too many open files - 无MVCC导致从库读取不到一致性快照，业务看到“订单已支付但库存未扣减”的中间态
- 扩缩容时，MyISAM表无法在线迁移（
ALTER TABLE ... ALGORITHM=INPLACE不支持），必须停服
真正容易被忽略的点是：InnoDB的可靠性不是靠“功能多”，而是靠整套机制咬合运转——redo log刷盘策略（innodb_flush_log_at_trx_commit=1）、binlog落盘（sync_binlog=1）、表空间管理（innodb_file_per_table=ON）三者缺一不可。一旦其中任一环为兼容旧系统调低，高可用就退化为“看起来可用”。
