01 它是干嘛的
GaussDB 是华为自研的关系型数据库，主打分布式与高可用，主要面向银行核心交易、运营商计费等对稳定性和数据一致性要求极高的场景。它的定位是替代原来大量依赖的国外商用数据库，让关键系统不被单一供应商卡住。
02 为什么会有它
一个账本放不下的年代：单机数据库的天花板
传统数据库像一本大账本，所有数据都存在一台机器上。数据量小的时候很好用，但银行的交易记录、运营商的通话详单动辄几十亿条，一台机器既存不下也算不动；想加机器，数据又没法自动分过去。
更麻烦的是停机风险。单机数据库一旦出故障，整个业务就停摆。为了不出事，只能买越来越贵的高端机器，成本高到普通人不敢想。
而且过去很多关键系统的数据库来自国外厂商，授权费昂贵，一旦断供或被限制，换起来极其困难。GaussDB 的目标就是在这类场景里，提供一个能横向扩展、能自动容灾、并且自主可控的选择。
03 它怎么工作
分布式数据库的核心是「分片」：把一张大表按某个规则拆成很多小块，分散到不同机器上，查询时由协调节点把任务派出去，各机器并行执行后再汇总结果。
一条查询是怎么被拆到多台机器上跑的
- 1① 解析 SQL
数据库先读懂你写的那句查询想干什么，把它翻译成内部能处理的表示。
- 2② 生成执行计划
优化器比较几种可能的执行方式，挑一个最快的，这一步决定了查询的快慢。
- 3③ 按分片键路由
根据建表时指定的分片规则（如按用户编号），判断这次查询涉及哪些数据节点。
- 4④ 各节点并行执行
相关节点各自处理自己那份数据，互不等待，整体速度大幅提升。
- 5⑤ 协调节点汇总
把各节点的结果收集起来，做合并、排序、去重等收尾工作。
- 6⑥ 返回结果
最后把完整结果返回给应用，整个过程对使用者是透明的。
04 谁在用它
账户、流水、转账等高频且要求强一致的场景，必须不出错、不停机。
海量通话与流量详单的存储与统计，对写入吞吐和数据规模要求极高。
需要长期稳定运行、数据不出境的系统，强调安全与自主可控。
财务、供应链等对数据一致性要求高的系统，容不得数据错乱。
电商、票务等瞬时写入量大的业务，靠分片横向扩展顶住压力。
05 怎么用
对使用者来说，写 SQL 的方式和普通数据库几乎一样，难点在于建表时怎么选分片键。
- 01在云上购买 GaussDB 实例，选择规格、节点数与部署区域。
- 02连接数据库，按业务需要建表，并指定分片方式（如按主键哈希）。
- 03为常用的查询条件建索引，避免全表扫描拖慢速度。
- 04用参数化查询写业务代码，避免拼接字符串带来的注入风险。
- 05配置主备与备份策略，定期演练故障切换。
- 06观察慢查询与资源使用，持续调整索引与分片策略。
-- 建一张分布式表，按 id 做哈希分片，分散到多个数据节点
CREATE TABLE orders (
id BIGINT PRIMARY KEY,
user_id BIGINT NOT NULL,
amount NUMERIC(12, 2),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) DISTRIBUTE BY HASH(id);
-- 建索引，加速按用户查询
CREATE INDEX idx_orders_user ON orders(user_id);
-- 查询：数据库自动在各数据节点并行执行再汇总
SELECT user_id, SUM(amount) AS total
FROM orders
GROUP BY user_id
ORDER BY total DESC
LIMIT 10;避坑提示
- !分片键一旦选定后期很难更改，建表前务必想清楚最常用的查询维度。
- !跨节点的分布式事务比单机昂贵，能避免就避免，尽量让一笔业务落在一个分片内。
- !索引不是越多越好，写入频繁的表上放太多索引反而会拖慢写入。
06 关键概念
- 分片
- 把一张大表按规则拆成多块分散存储，是横向扩展的基础。
- 分布式事务
- 一笔操作涉及多台机器时，保证要么全部成功、要么全部回滚。
- 高可用
- 主节点故障时能自动切到备用节点，业务几乎不中断。
- 共享存储
- 多个计算节点共用一份底层数据，兼顾扩展与一致性的方案。