MySQL Cluster适合高并发写密集、强一致、窄表结构的实时系统，如电信计费；不适用于复杂SQL、大字段或已有分片生态的场景。
MySQL集群（特指MySQL Cluster，即NDB Cluster）在特定高并发场景下表现优异，但并不适合所有高并发业务。它的适用性高度依赖请求类型、数据模型和一致性要求。
适合高并发读写的场景
MySQL Cluster基于内存存储+多节点同步复制，支持毫秒级响应和线性扩展写入能力，特别适合：
- 高频小事务场景：如电信计费、实时风控、游戏会话管理，单次操作数据量小、逻辑简单、QPS常达数万以上
- 强一致性+高可用刚需场景：节点故障时自动切换，无主从延迟，应用无需处理读写分离逻辑
- 读写混合且写占比高：相比主从架构，它不依赖binlog异步复制，写入可直接分发到多个数据节点并行处理
不适合的高并发场景
以下情况用MySQL Cluster反而会降低性能或增加运维成本：
- 复杂SQL查询多：不支持BLOB/TEXT索引、无JOIN下推优化，大表关联、子查询、GROUP BY等操作需拉取全量数据到SQL节点计算，延迟陡增
- 大字段或大事务频繁：NDB对单行大小有限制（默认14KB），长事务会阻塞全局schema锁，影响集群吞吐
- 已有成熟主从生态：如业务已依赖MyCat/ShardingSphere做分库分表，再引入NDB会增加架构复杂度，收益有限
与常见高并发方案对比
不是“用了集群就高并发”，关键看匹配度：
- 主从+读写分离：适合读远多于写的Web类应用（如电商详情页），成本低、兼容性强，但写仍是单点瓶颈
- Proxy分片（如Vitess、ShardingSphere）：适合数据量大、查询模式固定、能接受最终一致性的中大型业务
- MySQL Cluster：适合写密集、强一致、key-value或窄表结构为主、能接受一定SQL功能限制的实时系统
落地建议
若考虑MySQL Cluster，注意几个硬性前提：
- 数据模型必须扁平：尽量避免多表关联，核心业务表控制在10列以内，主键设计要利于数据均匀分布
- 网络质量要高：数据节点间通信频繁，跨机房部署需保障RTT
- 运维能力要匹配：备份恢复、在线扩容、内存监控、日志分析均不同于传统MySQL，需专门学习NDB运维规范
不复杂但容易忽略。选型前先用真实业务SQL压测NDB节点，重点看point-select和simple-insert的P99延迟，比看理论QPS更有说服力。
