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 更有说服力。
