MySQL NDB Cluster适合毫秒级故障切换、跨节点自动分片、高并发读写且数据量中等（几十GB到几百GB）的场景；它是内存优先的分布式键值存储，要求表有主键、不支持外键和完整TEXT/BLOB，JOIN慢、仅支持READ COMMITTED、DDL锁全集群。
MySQL NDB Cluster 适合什么场景
如果你的业务需要毫秒级故障切换、跨节点自动分片、高并发读写且数据量中等（几十GB到几百GB），NDB 才值得认真考虑。它本质是内存优先的分布式键值存储，表结构必须有主键、不支持外键约束、TEXT/BLOB 字段只能存前256字节（其余落磁盘但性能骤降）。常见踩坑：误把 NDB 当作“增强版 InnoDB”来用，结果发现 JOIN 极慢、事务隔离级别仅支持 READ COMMITTED、DDL 变更要锁全集群。
InnoDB 在 MySQL 集群里为什么仍是默认选择
哪怕你用了 MGR（MySQL Group Replication）或 InnoDB Cluster，底层还是靠 InnoDB 保证单机 ACID 和崩溃恢复。它的优势在于：支持完整事务、行级锁、MVCC、外键、全文索引、在线 DDL；对复杂查询友好，ORDER BY、GROUP BY、多表 JOIN 效率远高于 NDB。关键点：MGR 不是存储引擎，它只是基于 binlog + Paxos 协议做节点间状态同步，真正存数据的仍是每个节点上的 InnoDB。
选错存储引擎的典型症状
- 刚切到
NDB，发现SELECT COUNT(*) FROM orders要几秒——NDB没全局索引，这类聚合必须扫所有数据节点 -
INSERT延迟稳定在 10ms 以上，且随并发线程数线性上升——NDB的事务提交需跨网络协调，本地 SSD 再快也没用 - 执行
ALTER TABLE users ADD COLUMN phone VARCHAR(20)卡住整个集群十分钟——NDBDDL 是同步阻塞操作，且不支持ALGORITHM=INPLACE - 应用报错
ERROR 1296 (HY000): Got error 4009 'Cluster Failure' from NDBCLUSTER——说明管理节点（ndb_mgmd）不可达或数据节点失联，而InnoDB单机故障最多影响本节点
一个务实的决策路径
先问自己三个问题：
- 是否必须要求 99.999% 可用性，且能接受牺牲 SQL 功能和部分一致性？→ 否，则别碰
NDB - 当前瓶颈是单机磁盘 I/O 还是网络延迟？→ 如果是前者，
InnoDB配合 NVMe + buffer pool 调优更有效；如果是后者，NDB会放大问题 - 团队有没有人维护过
ndb_mgm、调过MaxNoOfConcurrentOperations或定位过Node failure handling日志？→ 没有，就等于没选好
真实生产中，95% 的 MySQL 集群需求靠 InnoDB + MGR/异步复制 + ProxySQL 就够了。NDB 是个特化工具，不是通用解法。最常被忽略的是：它没有真正的“备份”概念——mysqldump 导出的是逻辑快照，而 START BACKUP 命令产生的二进制快照必须用 ndb_restore 恢复，且无法按库/表粒度还原。
