目 录
回顾与导读：从"会用 NDB"到"选对方案"
第一章 传统主从集群：简单可靠的"老黄牛"
1.1 机制回顾
1.2 三大瓶颈
1.3 优点与适用场景
第二章 MGR 集群：基于 Paxos 的官方高可用
2.1 组复制机制
2.2 优势与局限性
2.3 MGR 与 NDB 的核心差异
第三章 中间件分库分表：把拆分的活交给应用层
3.1 代表方案与工作原理
3.2 中间件分片 vs NDB 原生分片
3.3 优点与痛点
第四章 四大方案核心维度总对比
4.1 CAP 视角的定位
第五章 精准选型：五类业务场景的答案
5.1 高并发实时业务（在线游戏、实时风控、实时推荐）
5.2 金融支付、电信计费类业务
5.3 普通业务（中小规模、读多写少）
5.4 海量数据业务（大数据量、复杂分析、归档）
5.5 已有 InnoDB 业务的渐进式改造
第六章 企业生产落地的选型避坑经验
6.1 六个高频踩坑点
6.2 选型决策四步法
读者收获与下一步
7.1 读完本篇，你应该带走什么
7.2 下一步建议
回顾与导读：从"会用 NDB"到"选对方案"
前四篇围绕 NDB 展开了完整的认知---原理---实操闭环。但真实的架构决策场景中，NDB 只是选项之一：主从复制、MGR、分库分表中间件都是生产环境里的常见方案，它们各有各的适用土壤。
这一篇跳出 NDB 本身，站在"架构选型"的高度，把四种主流方案放在同一坐标系下对比，并给出五类典型业务的精准选型建议。读完这一篇，你将不再纠结"哪个方案最好"，而是懂得"哪个方案最适合我的业务"。
特别提醒：选型没有银弹。下面的对比全部基于方案的技术本质，落到具体业务时，还需要结合团队运维能力、数据规模、成本预算综合判断------这正是本篇最后一章要讲的避坑经验。
第一章 传统主从集群：简单可靠的"老黄牛"
1.1 机制回顾
主从复制是 MySQL 最经典的扩展形态：主库处理写入并将变更写入 Binlog，从库拉取 Binlog 异步（或半同步）回放，实现数据冗余与读写分离。部署简单、生态成熟，是绝大多数业务的第一站。
1.2 三大瓶颈
1.3 优点与适用场景
- 优点：架构简单、学习成本低、工具链成熟、读写分离收益直接。
- 适用：中小规模业务、读多写少的应用、数据量可控、可容忍分钟级切换与少量延迟的业务。
一句话定位：主从复制是"够用就好"的方案，适合业务规模还没大到必须引入复杂架构的阶段。
第二章 MGR 集群：基于 Paxos 的官方高可用
2.1 组复制机制
MGR（MySQL Group Replication）是 MySQL 官方在 Binlog 复制框架之上、基于 Paxos 协议实现的分布式复制形态。组内成员通过多数派确认（Quorum）保证一致性：事务只有被组内多数节点确认后才提交。
- 单主模式：组内只有一个主节点可写，其余只读，主节点故障自动选举新主。
- 多主模式：组内多个节点可写，需应用保证冲突处理，实践中单主模式更常见。
2.2 优势与局限性
2.3 MGR 与 NDB 的核心差异
一句话定位：MGR 解决的是"InnoDB 生态内的高可用"------数据不拆分，节点互为镜像，靠 Paxos 保证不丢数据；NDB 解决的是"高可用 + 高并发 + 可扩容"------数据拆分，节点分工，靠同步复制保证一致。两者目标不同，并不冲突。
第三章 中间件分库分表：把拆分的活交给应用层
3.1 代表方案与工作原理
分库分表中间件分为两类：客户端分片（如 Sharding-JDBC/ShardingSphere-JDBC，在应用内完成路由）与服务端代理（如 ShardingSphere-Proxy、MyCat，独立部署转发 SQL）。核心思路一致：把一张大表按规则拆到多库多表，由中间件负责路由与聚合。
3.2 中间件分片 vs NDB 原生分片
3.3 优点与痛点
- 优点：底层仍是标准 MySQL，生态完全兼容；拆分粒度灵活（可库表双拆分）；适合"已有大量 InnoDB 业务"渐进式改造。
- 痛点一：业务侵入大------分片键选择影响所有查询，SQL 需按路由规则改写，跨片 JOIN/聚合受限。
- 痛点二：分布式事务复杂------跨库事务需引入外部协调器（如 Seata），性能与复杂度双高。
- 痛点三：扩容困难------分片数在设计时定死，二次扩容往往要重新分布全部数据，停机窗口长。
- 痛点四：多一层组件------客户端方案侵入应用代码，代理方案引入新的故障点与性能损耗。
一句话定位：分库分表中间件是"在标准 MySQL 之上手搓分布式"的方案，灵活但昂贵------所有分布式的复杂性都转移给了应用团队。
第四章 四大方案核心维度总对比
把四种方案放在统一坐标系下，从六个关键维度做横向对比（★ 越多代表该维度表现越强）：
从表可以读出三条规律：
- 写性能与扩容能力：NDB 遥遥领先，分库分表次之，主从与 MGR 受单写/全量冗余限制。
- 一致性与可用性：NDB 与 MGR 强，主从最弱，分库分表取决于底层配套。
- 运维成本与生态熟悉度：主从最友好，NDB 最专业------没有免费午餐，强能力对应高门槛。
4.1 CAP 视角的定位
从 CAP 理论看四种方案：
- 主从复制：AP 倾向（可用性优先，有短暂不一致窗口）。
- MGR：CP 倾向（Paxos 多数派保证一致性，牺牲部分可用性------少数派分区拒绝服务）。
- 分库分表：按分片维度拆解后，每个分片内部是单机 ACID，跨片弱一致。
- NDB：CP 倾向（同步复制强一致），但通过多副本+自动切换把"可用性损失"降到最低。
第五章 精准选型：五类业务场景的答案
选型必须落到业务。以下五类典型场景给出明确的推荐方案与理由。
5.1 高并发实时业务（在线游戏、实时风控、实时推荐）
推荐：NDB Cluster。这类业务读写并发双高、对延迟极其敏感、数据量中等（几十 GB 到几百 GB），正是 NDB 内存多主架构的主场。
5.2 金融支付、电信计费类业务
推荐：NDB Cluster（或 NDB + MGR 混合）。对 RPO=0、低延迟、无单点有硬性要求，且数据规模可控。电信计费本身就是 NDB 的诞生场景；支付核心库可用 NDB，周边账务查询类库可用 MGR 降低成本。
5.3 普通业务（中小规模、读多写少）
推荐：主从复制（读写分离），规模再大些、对可用性要求更高时升级 MGR。这类业务的核心诉求是"低成本获得可靠服务"，主从/MGR 完全够用，引入 NDB 反而增加运维负担。
5.4 海量数据业务（大数据量、复杂分析、归档）
推荐：分库分表中间件（配合 OLAP 数仓）。数据量达到 TB 级且以分析/归档为主时，NDB 的内存容量不现实，MGR 的磁盘容量也不够；分库分表把数据摊到多台标准 MySQL 上，配合归档链路才是正解。
5.5 已有 InnoDB 业务的渐进式改造
推荐：优先分库分表或 MGR，慎重引入 NDB。已有大量 InnoDB 表、复杂 SQL、外键依赖的业务，迁移到 NDB 需要大规模改造（主键、字段、SQL）；中间件分片或 MGR 的迁移路径更平滑。
第六章 企业生产落地的选型避坑经验
6.1 六个高频踩坑点
- 坑一：用主从的思维运维 NDB。NDB 是"集群"，不是"主从"。节点管理、配置分发、滚动升级的运维模型完全不同，团队需要专项学习。
- 坑二：把 NDB 当 InnoDB 用。拿现成的 InnoDB 表直接建 NDB 表，外键、TEXT、复杂 JOIN 全线踩雷------必须按 NDB 规范重新设计表。
- 坑三：忽视内存容量规划。NDB 数据在内存，上线前不核算 DataMemory，数据量一涨就触发内存告警甚至节点 OOM。
- 坑四：MGR 盲目开多主。多主模式对冲突处理要求极高，绝大多数团队 hold 不住，单主 + 秒级自动切换已经够用。
- 坑五：分库分表不留扩容余量。分片数按当前规模拍脑袋定，两年后要扩容，数据重分布让人崩溃------预留分片数或用一致性哈希。
- 坑六：混合方案叠加过度。NDB 里套分库分表、MGR 外面再套代理，每一层都在放大复杂性与故障面，能一层解决就不叠两层。
6.2 选型决策四步法
把上面的经验浓缩成可执行的决策流程：
- 第一步，量化需求：写并发、读并发、数据量、可用性目标（RTO/RPO）、延迟要求，逐项列出来。
- 第二步，匹配方案：按本章五类场景找到候选方案，至少备选两个。
- 第三步，做 POC：在真实数据规模与流量模型下压测候选方案，重点验证写入吞吐、切换时间、扩容演练。
- 第四步，评估团队：方案再先进，运维团队能否长期 hold 住才是最终决定因素------选团队养得起的方案。
最后一条忠告：架构选型的本质是"用合适的复杂度换合适的能力"。主从能解决的事，不要上 NDB；NDB 能解决的事，不要硬上分布式中间件。复杂度每高一层，都意味着真金白银的运维成本。