把传统单机 MySQL 替换为分布式数据库，最容易踩的坑是用单机思维设计分片与事务。要让 GaussDB 真正发挥横向扩展价值，必须把多写多读、分布式事务、故障自愈、PB 级存储、SQL 兼容与全栈安全这 6 项能力拆开看。GaussDB 基于共享存储与多节点并行架构，对外提供 MySQL/PG/ORA 三类兼容接口，并支持最大 256 个 DN 分片横向扩展，是政企核心系统替代大型机与小型机的常见路径。
一、GaussDB 必须覆盖的 6 项核心能力
数据库的”分布式”不是简单的多节点，而是把写入、事务、容错、扩展、兼容、安全 6 个维度同时升级。下面按维度梳理：
| 能力 | 解决的问题 | GaussDB 的实现要点 |
|---|---|---|
| 多写多读 | 单主节点成为写瓶颈 | 任意节点同时多写多读，负载动态调度 |
| 分布式事务 | 多分片写入一致性 | GTM 全局事务 ID + MVCC 快照 |
| 故障自愈 | 节点宕机导致业务中断 | 邻居故障检测算法，故障切换 < 6 秒 |
| 横向扩展 | 单机容量与并发受限 | 支持最大 256 个 DN 分片，PB 级存储 |
| SQL 兼容 | 迁移改造成本高 | MySQL / PostgreSQL / Oracle 三种兼容模式 |
| 全栈安全 | 政企合规与数据保护 | 行级访问控制、密态计算、数据动态脱敏 |
实测算例显示，基于通用计算超节点技术部署的 GaussDB 三节点集群每分钟可处理 540 万笔事务，对比鲲鹏平台集中式部署性能提升 2.9 倍；同时故障切换时间从传统的十余秒压到 6 秒以内，对金融级交易尤其关键。
二、GaussDB 的两种部署形态
GaussDB 同时提供”分布式版”和”集中式版”两条产品线，对应不同的容量与可用性诉求。
2.1 分布式版：面向 PB 级与高并发
分布式版由 CN 协调节点、GTM 全局事务管理器、DN 数据节点三部分组成，CN 负责解析 SQL 并下发执行计划，GTM 维护全局事务 ID，DN 负责存储与本地计算。三者通过 MPP 大规模并行处理架构联动，可做到数据扫描、表连接、数据聚合全流程并行。
2.2 集中式版：面向中等规模核心系统
集中式版采用 1 主 2 备或 1 主 1 备 1 日志的部署形态，适合数据量中等、对可靠性有刚性要求但不需要横向扩容的场景。其运维链路更短，更贴近传统 Oracle 的运维习惯。
下表给出两种形态的差异：
| 形态 | 数据规模 | 扩展性 | 节点数 | 典型场景 |
|---|---|---|---|---|
| 分布式版 | PB 级 | 支持横向扩容 | 默认 3CN + 9DN（独立部署） | 详单查询、交易型大并发 |
| 集中式版 | TB 级 | 不支持横向扩容 | 3 节点或单副本 | 政企中型核心、边缘业务 |
三、GaussDB 与单机 MySQL 的关键差异
很多团队在迁移时只看”语法兼容”，忽略了事务模型与容错机制的差异。要在 GaussDB 上平稳运行业务，至少要把以下 4 点搞清楚：
- 事务模型不同：MySQL 单机的 binlog 主从复制只能保证最终一致，GaussDB 通过 GTM + MVCC 提供全局强一致快照，跨节点读写无延迟偏差；
- 扩展机制不同：MySQL 横向扩展依赖分库分表（应用层改造），GaussDB 由 CN 统一调度分片，应用层无感；
- 故障切换不同：MySQL 主从切换通常 10-30 秒，GaussDB 邻居故障检测算法把切换时间压到 6 秒内；
- 兼容模式不同：GaussDB 同时提供 MySQL、PostgreSQL、Oracle 兼容端口，可以分阶段切换数据源。
下面给出一段 GaussDB 兼容 MySQL 模式下的建表示例（仅作语法参考）：
-- GaussDB 兼容 MySQL 模式：订单表按 user_id 哈希分片
CREATE TABLE t_order (
id BIGINT NOT NULL,
user_id BIGINT NOT NULL,
amount DECIMAL(18,2) NOT NULL,
status TINYINT NOT NULL DEFAULT 0,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (id)
)
DISTRIBUTE BY HASH(user_id)
TO GROUP group_1;建表后写入数据前，先在 CN 节点上观察分片分布情况，确认 user_id 哈希值落在预定的 DN 上，再分批灌入历史数据，能避免后期出现”热点 DN”。
四、迁移上云时的 3 个易错点
替换大型机或 Oracle 一体机时，团队常在以下 3 个位置踩坑：
- 序列与全局唯一 ID 仍依赖应用层发号器——GaussDB 提供 sequence 序列对象，应该把发号迁到数据库侧，减少应用代码的耦合；
- 长事务未做拆分——分布式事务的锁占用会被放大到所有分片，超过 30 秒的事务建议在应用层拆成短事务；
- 备份策略按单机节奏设置——GaussDB 默认 7 天自动备份，跨 AZ 部署时应在每个 AZ 单独配置 OBS 桶，避免单桶带宽成为瓶颈。
五、运维与可观测性
GaussDB 提供 DAS 数据管理服务、DRS 数据复制服务、Cloud Eye 监控告警三层工具链。日常运维建议把慢 SQL 阈值设为 200ms，事务执行超过 1 秒即触发告警；备份恢复演练每季度至少一次，验证 RPO 与 RTO 能否满足核心业务要求。
到这一步，GaussDB 的能力地图、部署形态、与单机 MySQL 的差异以及迁移易错点就完整了。下一步通常是按业务优先级把核心交易先迁到集中式版，再把详单查询与历史库迁到分布式版。
常见问题（FAQ）
Q1：GaussDB 分布式版最多能扩展到多少节点？
支持最大 256 个 DN 分片横向扩展，单集群容量可达 PB 级。
Q2：GaussDB 与 MySQL 的语法兼容度是多少？
兼容 MySQL 5.7、8.0 主要语法对象，少数自定义函数与存储过程需适配。
Q3：分布式事务会不会比单机事务慢很多？
GTM 全局事务管理器在同 AZ 内的延迟通常在毫秒级，业务侧感知不明显。
