PolarDB 是阿里云推出的云原生关系型数据库，基于计算与存储分离的分布式架构，同时兼容 MySQL、PostgreSQL 与 Oracle 语法。对于长期被单机实例容量上限、读写扩容慢、备份恢复耗时折磨的团队，PolarDB 提供了一键弹性扩容与近乎无限的存储增长能力。本文从架构原理讲起，带你完成一次从自建 MySQL 到 PolarDB 的平滑迁移，并给出生产落地清单。
一、PolarDB 是什么：云原生数据库的官方定位
传统关系型数据库（如自建 MySQL、Oracle）大多是“计算与存储紧耦合”的单机或主从架构：磁盘挂在某台机器上，要扩容要么升级规格（垂直扩容，有上限），要么加从库（水平读扩展，但写仍是单点）。PolarDB 的核心思路是把“计算”和“存储”彻底拆开——多个计算节点共享同一份底层分布式存储，从而同时获得弹性、高可用与低成本。
目前 PolarDB 提供三个兼容引擎：PolarDB for MySQL、PolarDB for PostgreSQL、PolarDB for Oracle（简称 PolarDB-O）。对绝大多数业务而言，前两者最常用，迁移成本极低，因为应用侧几乎不用改 SQL。
二、架构核心：计算存储分离与共享存储
2.1 计算节点无状态化
PolarDB 的每一台计算节点（DB 节点）都是无状态的：它不持有数据文件，只负责 SQL 解析、优化与执行。多个节点挂载同一份共享存储，一写多读。这意味着扩一个只读节点只需要拉起一个计算进程，不用拷贝任何数据，分钟级完成。
2.2 分布式存储 PolarFS
底层存储基于自研的 PolarFS，将数据切分为 chunk 分布在多个存储节点上，通过多副本（默认三副本）保证可靠性。计算节点通过用户态文件系统协议访问，对上层数据库而言仍是一个“普通的块设备”。逻辑架构可以简化为：
┌──────────── 共享存储 PolarFS (三副本) ────────────┐
│ Chunk A │ Chunk B │ Chunk C │
└─────────────┴─────────────┴────────────────────┘
↗ 读/写 ↑ 读 ↑ 读
[主节点 RW] [只读节点 RO1] [只读节点 RO2]
(唯一写入) (水平扩展) (水平扩展)由于只读节点直接读共享存储的最新页面（通过 redo 日志追平），它天然避免了传统主从复制的“复制延迟”问题，延迟通常在毫秒级。
三、PolarDB vs 传统 RDS：为什么选云原生
同为托管关系型数据库，PolarDB 与经典 RDS（主从架构）的差异主要体现在扩展模型上：
| 对比维度 | 传统 RDS 主从 | PolarDB 计算存储分离 |
|---|---|---|
| 只读扩展 | 加从库需全量数据复制，慢 | 挂载共享存储，分钟级拉起 |
| 存储上限 | 受单机磁盘限制（通常 TB 级） | 共享存储，最高可达百 TB 级 |
| 备份恢复 | 依赖物理/逻辑备份，恢复慢 | 基于存储快照，秒级恢复 |
| 写能力 | 单主写入 | 单主写入（同 RDS） |
| 成本结构 | 计算+存储绑定计费 | 计算与存储独立计费，只读节点不重复买存储 |
简单说：如果你的瓶颈是“读多写少、需要频繁扩只读、数据量增长快”，PolarDB 的收益最明显。关于索引与执行计划的底层原理，可参考 MySQL 索引底层原理：B+树、覆盖索引与最左前缀，迁移后优化思路完全一致。
四、快速上手：Docker 部署 PolarDB for PostgreSQL
本地验证可以用官方提供的单机版镜像（PolarDB-PG 的轻量形态），快速体验兼容协议：
version: "3"
services:
polardb:
image: polardb/polardb-pg:latest
container_name: polardb-pg
environment:
- POSTGRES_PASSWORD=yourStrongPassword
- POSTGRES_DB=appdb
ports:
- "5432:5432"
volumes:
- polardb_data:/var/lib/postgresql/data
volumes:
polardb_data:用 docker compose up -d 拉起后，它对外暴露的仍是标准 PostgreSQL 5432 端口，普通的 psql、JDBC、ORM 都能直接连。如果你还不熟悉 Compose 编排，可先看 Docker Compose 一键编排：MySQL + Redis + 后端服务 打基础。
五、协议兼容：应用零改造迁移
PolarDB for MySQL 100% 兼容 MySQL 协议与主流语法，意味着你原来的连接串、驱动、ORM 几乎不用改。以 Java 应用为例：
// 原自建 MySQL 连接串
jdbc:mysql://10.0.0.5:3306/appdb?useSSL=false
// 迁移到 PolarDB 后，仅改 host/port，其余不变
jdbc:mysql://pc-2ze****.rwlb.rds.aliyuncs.com:3306/appdb?useSSL=true&serverTimezone=Asia/ShanghaiPostgreSQL 引擎同样兼容标准协议，psql -h <polardb-endpoint> -U admin -d appdb 即可连入。若你的业务重度依赖 PG 特性，可对照 PostgreSQL vs SQL Server：语法差异与迁移避坑指南 做语法层面的二次确认。
六、平滑迁移实战：从自建 MySQL 到 PolarDB
6.1 结构迁移
先用 mysqldump 仅导出表结构，在 PolarDB 侧预创建，提前暴露不兼容的存储引擎或语法差异：
# 仅导出结构（不带数据）
mysqldump -h 10.0.0.5 -u root -p --no-data appdb > schema.sql
# 在 PolarDB 创建库并导入结构
mysql -h pc-2ze****.rwlb.rds.aliyuncs.com -u admin -p -e "CREATE DATABASE appdb;"
mysql -h pc-2ze****.rwlb.rds.aliyuncs.com -u admin -p appdb < schema.sql6.2 数据迁移与增量同步
结构就绪后，有两种主流方式。小数据量可直接 mysqldump 全量导入；大数据量或要求“几乎零停机”，推荐用数据传输服务（DTS）做全量+增量（binlog）同步，源库持续写入时也能追平。核心命令思路：
# 全量导出（含数据）
mysqldump -h 10.0.0.5 -u root -p --single-transaction --routines --triggers appdb > full.sql
# 导入 PolarDB（建议先临时关外键检查加速）
mysql -h pc-2ze****.rwlb.rds.aliyuncs.com -u admin -p appdb < full.sql6.3 一致性校验与切换
切换前务必做行数/校验和比对，确认两端一致后再把应用连接串切到 PolarDB 端点。校验示例：
-- 两端分别执行，对比行数
SELECT COUNT(*) FROM orders;
SELECT COUNT(*) FROM order_items;
-- 关键表校验和（借助 CRC 思路）
SELECT SUM(CRC32(CONCAT_WS(',', col1, col2, col3))) FROM big_table;关于主从一致与读写分离的设计，MySQL 主从复制与读写分离：高可用架构实战 里讲的延迟与路由问题，在 PolarDB 只读节点场景下同样适用，建议一并阅读。
七、性能与扩展：只读节点与弹性
迁移完成后，真正的红利是弹性。读压力上涨时，在控制台一键增加只读节点，应用侧把分析类查询指向只读端点即可：
# 写流量走主节点端点
jdbc:mysql://pc-2ze****.rw.rds.aliyuncs.com:3306/appdb
# 读流量（报表/搜索）走只读负载均衡端点
jdbc:mysql://pc-2ze****.ro.rds.aliyuncs.com:3306/appdb把耗时报表、批量导出等读请求分流到只读节点，主节点专注写入，整体吞吐立竿见影。需要更细粒度参数调优时，MySQL 深度调优：核心参数与执行计划解读 里的 innodb_buffer_pool_size、慢查询日志等手段在 PolarDB 上依然有效。
八、生产落地检查清单
| 检查项 | 要点 |
|---|---|
| 兼容性预检 | 导出结构在 PolarDB 跑通，消灭存储引擎/语法差异 |
| 数据一致性 | 全量+增量同步完成，行数与校验和两端一致 |
| 连接安全 | 启用 SSL，白名单限制来源 IP，避免公网裸奔 |
| 高可用 | 至少 1 个只读节点，验证故障切换演练 |
| 监控告警 | 接入慢查询、连接数、CPU 指标告警 |
| 回滚预案 | 保留原库一段时间，异常可切回 |
把迁移验证放进流水线更稳妥：在 CI 中跑一遍结构兼容性测试与数据校验脚本，可参考 GitHub Actions 实战：从零搭建 CI/CD 流水线 把校验步骤固化下来。
九、总结
PolarDB 的价值不在“又一个 MySQL”，而在于用计算存储分离把数据库的弹性瓶颈打碎：只读扩展从“搬数据”变成“拉进程”，存储从“单机磁盘”变成“共享池”，备份恢复从“小时级”变成“秒级快照”。对于读多写少、数据增长快、追求高可用的业务，它是性价比极高的云原生升级路径。迁移本身并不痛苦——协议兼容意味着应用几乎零改造，真正要花心思的是一致性校验与回滚预案。把这两件事做扎实，一次平滑迁移就能换来长期的运维轻松。
