云数据库只支持innodb是因为myisam等引擎在分布式高可用云场景下不可靠、不可控：无redo/undo日志致崩溃后丢数据、不支持热备份与增量同步、无法适配云存储抽象与智能诊断、缺乏行级锁和mvcc导致扩缩容与读写分离失效。
云数据库厂商只提供 InnoDB，不是技术懒惰，而是把 MyISAM、MEMORY 等引擎从生产环境里“物理下线”了——因为它们在分布式、高可用、自动运维的云场景下，既不可靠，也不可控。
MyISAM 在云环境下会直接触发数据安全告警
云数据库默认开启崩溃自动恢复、热备份、主从强同步等能力，而 MyISAM 没有 redo log 和 undo log，系统崩溃后只能靠 myisamchk 人工修复，且大概率丢数据。云平台无法容忍这种“修复即停服、修复即风险”的行为。
- 一旦实例异常重启，
MyISAM表可能处于crashed状态，云控制台会立刻标记为“异常实例”，触发告警甚至自动隔离 -
mysqldump备份时需加--lock-tables，整库锁表几分钟——这和云服务承诺的“备份不中断业务”直接冲突 - 没有事务日志，就无法做基于位点的增量同步，主从延迟监控、binlog 回溯、逻辑订阅等功能全部失效
云数据库的底层存储抽象依赖 InnoDB 的表空间模型
腾讯云、阿里云、AWS RDS 的存储层都深度集成了 InnoDB 的 innodb_file_per_table（8.0 默认开启）和独立表空间（.ibd 文件），这是实现单表回收、在线迁移、快照克隆、冷热分层的基础。
- 每个表对应一个可独立挂载/卸载的
.ibd文件，云平台才能按需调度 IO、压缩、加密、归档 -
MyISAM的.MYD+.MYI分离结构无法被统一管理，也无法支持透明页压缩（如innodb_file_format=Barracuda） - 云厂商的智能诊断（如慢查归因、索引推荐、空间膨胀分析）全部基于
InnoDB的INFORMATION_SCHEMA.INNODB_TABLESTATS等内部视图，MyISAM没有等效指标源
并发与弹性扩缩容必须依赖行级锁和 MVCC
云数据库的“按量付费”“秒级升配”“读写分离自动路由”这些能力，底层全靠 InnoDB 的 row-level locking 和 MVCC 支撑。换成 MyISAM，扩到 16 节点也没用——一写全表锁，所有只读节点也会被阻塞。
- 连接池复用、短连接高频建连场景下，
MyISAM的表打开缓存（table_open_cache）极易打满，引发Too many open files错误 - 无 MVCC 就无法实现真正的“一致性读”，读写分离时从库查到的数据可能是中间态，云平台无法对 SLA 做任何一致性承诺
- 自动读写分离代理（如 ProxySQL、RDS 内置 Proxy）依赖
InnoDB的事务状态（TRX_STATE）做流量染色和路由决策，MyISAM查询一律视为“非事务型”，被强制走主库
真正要警惕的不是“为什么只支持 InnoDB”，而是你还在本地开发环境用 ENGINE=MyISAM 建表——上线前云平台会静默转成 InnoDB，但 ALTER TABLE ... ENGINE=InnoDB 可能锁表数分钟，且原来依赖 MyISAM 全文索引或 COUNT(*) 快速统计的逻辑会突然变慢或报错。
