副标题：什么业务不该上分布式，以及判据为什么是 2w tps 和 24T
这个问题在 GaussDB 选型时会被反复问起。多数人的第一反应是"量大了就上分布式"，但真正的答案不是比性能高低，而是看三把尺子------写 tps、规划容量、以及你改不改得动分片键。下面先把结论摆出来，再讲依据。
结论
集中式是"一台机器扛到底"：数据都在一块，写只有主 DN 一个出口，顶得住写 2w tps、24T 规划容量；分布式靠加节点突破这个顶。
所以过线才谈分布式。分片键改不动就别硬上，拆成几个小库更划算------那还是集中式。
一、先看清差别：少的不是性能，是两个组件
官方对 GaussDB 的定义是"基于 Shared-Nothing 架构的分布式数据库"，主要包含 GTM（全局事务管理器）、OM（运维管理）、CM（集群管理）、CN（协调节点）和 DN（数据节点）等模块。
把两种形态的逻辑架构并排看，差别很直观：
于是就有一条最直接的推论：
集中式没有 CN------请求不用先过一层协调节点，所有读写直接落在同一个主 DN 上；
集中式没有 GTM------不存在跨节点事务，也就不需要全局事务协调。
这解释了集中式为什么"应用可以完全不动"，也解释了它为什么天花板只能是单机。
二、官方给的三把尺子
2.1 并发：2w tps
集中式：一写多读，2w tps 以下业务场景。分布式：多读多写，2w tps 以上业务场景。------《HCIE-GaussDB V2.0 培训教材》P42
为什么卡在写这一侧：集中式加备 DN 只扩读、不扩写，写永远压在主 DN 上。单 DN 的吞吐受 CPU、内存、IO 三重限制，tps 越高，WAL 写入和随机读同步上涨，磁盘 IOPS 往往比 CPU 更早撞墙。换更强的硬件，这个拐点会跟着移动------所以 2w 是主流硬件规格下的工程口径，不是物理常数。
2.2 数据量：24T 规划容量
业务需求数据量＝业务初始数据量×（1+年平均增长百分比）^年数÷资源利用率控制水位；如果业务需求数据量 > 24T，建议拆成多个小数据库，或者选择分布式多分片形态。------《HCIE-GaussDB V2.0 培训教材》P26
这里有三个容易踩的点：
24T 是规划容量，不是今天的存量。公式里带年数和增长率，通常按三年规划算。
24T 不是实际可用空间。教材同一章节的"注意"写得很清楚：数据库所规划的数据容量是指已经考虑了扩展策略、预留策略之后的数据容量，并非实际可用空间；比如 24T 的数据空间，内核默认 85% 会触发只读保护，实际可用空间只有 20T 左右。
扩容有步长。分布式形态扩分片按 Group 为单位：初始 3C3D，扩容步长就是 3 的整数倍；初始 4C4D，步长就是 4 的整数倍。
2.3 SQL 复杂度与改造能力
集中式形态：业务 SQL 复杂改造困难、业务性能和数据量要求相对可控的稳态业务等场景，建议优先推荐。分布式形态：业务 SQL 相对简单或业务具备改造条件、业务性能要求和数据量要求不可控的敏态业务等场景，建议优先推荐。------《HCIE-GaussDB V2.0 培训教材》P43
这一条最容易被忽略，却最能决定项目成败。分片键选错、SQL 改不动，上分布式不会更快，只会更慢------原因见第四节。
三、算一算：8T 起步，增长率决定结论
假设某业务初始数据量 8T、年平均增长 25%、规划 3 年、资源利用率水位按 85%：
决策点是三年后的规划容量，不是今天的存量。
另一个容易被混用的数：复算结果要和 24T（规划容量）比；教材 P42 那句"实际可用空间只有 20T 左右"是 24T 再扣掉 85% 只读水位后的可用空间，属于另一层意思------两个数混着比，会算出互相矛盾的结论。
四、为什么
1. 现象层：一个查询到底落在几台 DN 上
集中式只有一台主 DN 承接，所有连接都打向同一个主节点。一主多备里的备能接受只读查询，但只有显式连到它的请求才走它------应用不做读写分离，读同样压在主 DN 上。
分布式是另一套路径：CN 解析 SQL，按分片键把分片下发给多个 DN 并行执行，再把结果汇总回来。同一个查询，在分布式上落在 N 台 DN 上。
2. 机制层：单 DN 的 tps 为什么会撞墙，CN 又卡在哪
单 DN 的吞吐受 CPU、内存、IO 三重限制，磁盘 IOPS 常先撞墙（见 2.1）。
加 DN 能接近线性扩展，前提是数据被均匀切分、负载跟着分片一起被切开。分片一旦倾斜（热点分片），线性立刻失效------这正是"分片键选错会让分布式反而不如集中式"的根源。
CN 只做解析、路由、汇总，不存业务数据。跨 DN 的 JOIN、排序、聚合都在 CN 上收口，SQL 越复杂，CN 越先顶不住------它救不了容量，反而是新的瓶颈位置。
3. 设计层：为什么分布式要改分片键，集中式却不用动应用
分片键决定数据落在哪个 DN，是 Shared-Nothing 落地的前提。它难改，是因为业务的访问模式------高频 JOIN、跨表更新、热点行------通常不按单一键局部化。键一旦选错，跨分片 JOIN 和分布式事务变多，性能反而不如集中式。
跨 DN 提交还要走 2PC + GTM 协调，提交延迟变长、失败面变大。GTM 的全局事务 ID 与全局快照，是给每个事务一个全局一致的时间点视图，支撑跨 DN 的一致性读。
集中式的所有请求落在同一主 DN，不存在跨节点一致性协调这件事，所以应用可以完全不动。
小结
集中式把上限锁死在单台主 DN；分布式用分片把负载也切开换来线性扩容，代价是数据局部性必须由应用的分片键保证，再由 GTM + 2PC 兜一致性、CN 兜汇总与聚合。
五、什么业务不该上分布式
判定前先说清两件事：在什么环境（集中式／分布式）、条件从多少变到多少。否则"成立不成立"没有参照物。
两个容易混的名词：跨表 JOIN 与跨分片 JOIN
跨表 JOIN：SQL 里两张以上表做关联就算，跟用 Hash Join 还是 Nested Loop 无关------那是算子选择，不是连接类型。
跨分片 JOIN：执行层面的事------参与关联的表被切在不同 DN 上，任何一个 DN 都凑不齐两边的数据，必须先搬（按连接键重分布，或小表广播）才能算。集中式所有表同在一个 DN，跨表 JOIN 天然是本地 join，这一层开销根本不存在。
代价在哪：分片键与连接键对不上时，成本是网络传输＋临时空间＋多轮往返；Nested Loop 尤其致命（外表每行都可能触发一次跨节点访问）。再叠加跨 DN 事务的协调开销，才出现"性能还不如集中式"------不是分布式算得慢，是数据要多跑一趟网络。
一条"看起来对但实际会翻车"的判断
看起来对：数据量或并发翻 10 倍，那就转分布式。
为什么会翻：翻 10 倍只说明越过了集中式的阈值（24T／2w tps），它证明的是"集中式装不下"，不等于"分布式就该上"。转之前还有三笔账要算：
-
分片键能不能改------改不了，热点压在个别 DN 上，还多出跨分片 JOIN；
-
SQL 有多复杂、存储过程有多少------跨分片协调的开销会吃掉扩容收益；
-
改造和运维成本------应用要改、要调优，日常还多一套 CN／GTM 要看。
三笔账不划算时，正确动作是拆库：把一个大库拆成几个小库，形态仍然是集中式。教材 P26 给的本来就是两个选项------"拆成多个小数据库，或者选择分布式多分片形态"，不是单选题。
翻车的具体样子：30T 数据、一堆跨表 JOIN 和存储过程，硬上分布式后跨分片 JOIN 把性能吃掉，反而不如拆成 3 个 10T 的集中式小库。
六、延伸问题：分布式下一条 SQL 到底在 CN 算还是 DN 算
这是顺着本文第四节自然长出来的问题。官方口径是优化器会选三种执行计划：
下推语句计划（FQS）：整条 SQL 从 CN 直接发到 DN 执行，DN 全做完只把结果返回 CN；
分布式执行计划（Stream）：CN 编译出计划树下发，各 DN 执行自己那部分，中间用 Streaming 算子搬数据（广播、重分布、汇聚三种）；
发送语句的分布式计划：只有基表扫描下推，中间结果全拉回 CN，剩下的在 CN 算------官方明确说这会让 CN 成为性能瓶颈。
判断办法是看执行计划：第一行是 Data Node Scan 且没有算子树，说明语句级下推；出现 Streaming 说明在 DN 间搬数据；出现 Data Node Scan 但带REMOTE_TABLE_QUERY标记，就是最差的那种------只看节点名很容易把最差当最好。
七、官方出处
GaussDB 产品介绍（26.861.0）第 3 章软件架构：架构总述、组件构成、图 3-1／3-2／3-3／3-4、表 3-1 组件说明
https://doc.hcs.huawei.com/db/zh-cn/gaussdbqlh/26.861.0/doc/download/pdf/gaussdbqlh-productdesc.pdf
GaussDB 安装指南 · 本地磁盘安装实例：部署形态（集中式／分布式／单机）选择与安装模式差异
https://doc.hcs.huawei.com/db/zh-cn/gaussdbqlh/26.861.0/install/qlh_06_0118.html
GaussDB 分布式 · 语句下推调优：三种执行计划、下推规则、REMOTE*QUERY 标志判读
https://doc.hcs.huawei.com/db/zh-cn/gaussdb/2.23.07.210/devg-dist/gaussdb-12-0262.html
教材：《HCIE-GaussDB V2.0 培训教材》P18、P26、P42、P43
实验：《HCIE-GaussDB V2.0 实验手册》6.2 部署方案设计及资源准备（P234--237）
最后一句：选型不是比谁性能高，是比"你的写和数据量会不会被单机锁死，以及你改不改得动"。越阈值 ≠ 必须转分布式。