01 它是干嘛的
PolarDB 是阿里云自研的云原生关系型数据库，核心是计算与存储分离：多个计算节点共享同一份存储数据，一写多读。它兼容 MySQL、PostgreSQL 等主流数据库，解决传统数据库「扩容要搬数据、耗时长、业务要停机」的难题。
02 为什么会有它
过去给数据库扩容，为什么要停机好几个小时
传统数据库把计算和存储放在同一台机器上：数据库软件负责算，硬盘负责存，两者绑在一起。数据变多或访问变多时，唯一的办法是把整台机器换成更强的，再把数据从旧机器复制到新机器。这份数据动辄几百 GB 甚至几个 TB，搬一次要几个小时，期间业务要么变慢、要么停机。
更尴尬的是读多写少的业务。一个订单只能写一次，却会被查很多次（用户查订单、后台统计、对账）。传统做法是加若干台只读副本，各自复制一份完整数据，把读请求分散出去。但副本越多，复制数据占用的带宽与延迟越大，数据一致性也越难保证。
PolarDB 换了个思路：把存储从计算里单独拿出来，做成一份所有节点共享的分布式存储。计算节点只负责算，需要数据时直接向共享存储要，不再各自复制一份。于是「加一个读节点」变成了「多接一个计算节点」，几分钟就能完成，也不用搬数据。
03 它怎么工作
所有计算节点共享同一份存储，写节点把数据改动写入共享存储，读节点按需读取同一份数据，因此新增读节点几乎不需要复制数据，扩容从小时级降到分钟级。
一写多读是怎么实现的：共享存储加计算节点
- 1① 计算存储分离
存储层是一套分布式存储集群，负责持久化数据；计算层是若干可独立伸缩的数据库进程。
- 2② 主节点负责写
所有写请求都发给主节点，它把改动写入共享存储，保证同一份数据只有一个写入口。
- 3③ 只读节点共享读
读节点直接读取共享存储里的同一份数据，无需复制整库，因此可以快速增加。
- 4④ 数据改动即时可见
主节点写入后，读节点能很快看到最新数据，避免了传统副本复制延迟带来的「读到旧数据」。
- 5⑤ 快速扩容与故障切换
加读节点只需几分钟；主节点故障时，某个读节点可被提升为新的主节点，减少停机时间。
04 谁在用它
订单、账户等强一致业务，主节点保证写入正确，多个读节点分担查询与报表压力。
内容、商品、资讯类应用读取远多于写入，加读节点即可线性提升查询能力。
兼容 MySQL 的语法与协议，应用几乎不用改代码，即可获得弹性与高可用。
大促或活动期间临时增加读节点，活动结束再释放，成本与能力随业务弹性变化。
结合全球数据库能力，把数据同步到异地，主地域故障时可切换到备地域继续服务。
05 怎么用
会用 MySQL 就能上手，因为 PolarDB 兼容 MySQL 协议；难点在于理解集群管理与只读节点的读写分离。
- 01在控制台创建 PolarDB 集群，选择兼容版本（MySQL 或 PostgreSQL）、规格与存储容量。
- 02设置白名单，只允许应用所在的网络访问集群。
- 03获取集群的主地址（用于写）与只读地址（用于读），在应用里分别配置。
- 04应用连接时把写操作走主地址、读操作走只读地址，实现读写分离。
- 05需要更高并发时增加只读节点；定期依赖自动备份与快照做恢复演练。
-- 写操作：连接主地址
INSERT INTO orders (id, user_id, amount, created_at)
VALUES (1001, 42, 299.00, NOW());
-- 读操作：连接只读地址（可分散到多个只读节点）
SELECT id, amount, created_at
FROM orders
WHERE user_id = 42
ORDER BY created_at DESC
LIMIT 20;避坑提示
- !读写分离要靠应用或中间件配合，别把写请求也发到只读地址，否则会报错或数据不一致。
- !只读节点本身有成本，长期用不到的低频节点应及时释放。
- !迁移前先在测试环境跑一遍完整业务，确认语法兼容性、字符集与权限配置都一致。
06 关键概念
- 计算与存储分离
- 数据库的算力与数据存放相互独立，算力可按需增减，而数据只有一份。
- 一写多读
- 只有一个节点负责写入，多个节点负责读取，保证写入唯一、读取可扩展。
- 只读节点
- 不接收写入、只提供查询的数据库实例，用来分担读取压力。
- 兼容性
- PolarDB 尽量与 MySQL、PostgreSQL 保持语法与协议一致，降低迁移与学习成本。