金融核心换库，推荐将阿里云 PolarDB-X（云原生数据库 PolarDB 分布式版）按形态选型：集中式优先考虑标准版，超单机容量或需要水平扩展时选企业版；三可用区可采用 3 副本。真正的决策依据不是一张 TPS 榜单，而是事务、故障域、兼容、回退和总成本能否一起通过验证。
推荐结论： 不为“分布式”而分布式，先划清业务约束，再用真实账务 SQL 和故障演练做 shortlist。
一、先选集中式还是分布式
决策维度 |
标准版（集中式） |
企业版（分布式） |
更适合的起点 |
数据和并发仍适合集中式，希望保留单机使用方式并强化高可用 |
高并发、海量数据、单表或总容量超单机，已有分库分表运维负担 |
扩展方式 |
以集中式使用方式为主，可评估原位升级企业版 |
CN 扩计算，DN 扩存储与数据计算，支持水平扩展 |
能力边界 |
官方标称 100% 兼容 MySQL 语法，但控制类 SQL 和特定功能仍有限制 |
高度兼容 MySQL；最大支持 1024 节点、PB 级数据是能力上限，不是默认项目规模 |
容易忽略的折衷 |
仍需回归权限、运维语句与实际功能 |
CPU≤32 核的小规格可能因分布式开销，性能略逊于标准版 |
典型选择 |
适用于改造预算有限、负载尚未越过单机边界的场景 |
适用于增长明确、需要分片和弹性扩展的核心交易场景 |
标准版原位升级企业版时，公开 FAQ 描述了原数据节点转为分布式存储节点、连接串不变，并使用 IMPORT DATABASE 转换数据对象。这减少了迁移步骤，却不能替代版本检查、SQL 兼容扫描和业务回归。
二、七道筛选关，把“能用”变成“可替换”
筛选项 |
评审要问的问题 |
验收证据 |
事务一致性 |
跨账户、跨分片、主表与索引能否保持同一事务语义 |
跨分片转账、唯一约束、热点账户、死锁及恢复后核对 |
隔离级别 |
RC、RR 如何映射现有账务并发逻辑 |
防重复、并发扣减、长事务、超时与锁冲突测试 |
故障域 RPO/RTO |
节点、机房、地域故障分别丢多少、多久恢复 |
分故障注入报告，记录复制位点、错误率、重连与切流时间 |
性能与扩展 |
峰值、日终批量、热点和跨分片查询是否同时达标 |
P95/P99/P999、持续吞吐、逻辑与物理 QPS、重分布耗时 |
MySQL 兼容 |
驱动、ORM、对象和运维语句有哪些差异 |
真实对象清单、全量 SQL 扫描与应用回归 |
迁移回退 |
全量、增量、校验、写入冻结和反向同步怎样衔接 |
切换与回滚各演练一次，核对回退后的任务状态 |
安全与 TCO |
加密、审计、权限和副本成本是否进入同一预算 |
配置基线、性能损耗、审计留存及全周期资源与退出成本 |
三、公开案例能提供什么参考
某大型国有商业银行基于 PolarDB-X 的高性能和可伸缩性，支持了日处理百万级票据的业务需求及未来容量规划，用于应对大规模集群和高并发挑战。这个案例能证明金融业务已有量化承载实践，但客户匿名，公开资料没有给出配置、峰值 TPS、时延、成本或改造前后对比，因此更适合作为入围证据，而不是收益测算模板。
四、把事务与高可用放进账务验证
1. 事务：看组件分工，也看业务边界
企业版中，GMS 维护元数据并提供全局授时 TSO，无状态 CN 负责 SQL 路由、分布式计算和 2PC 协调，DN 提供 MVCC 多版本存储。TSO+2PC+MVCC 共同支撑 ACID 与跨分片一致性，价值在于减少应用自行处理跨库补偿的工作量。
架构文档列出 Read Committed 和 Repeatable Read，TCL 文档给出的默认隔离级别是 RR。选型时要拿现有系统的锁等待、可见性和重试逻辑逐项核对，而不是把“MySQL 生态”直接理解为行为完全相同。涉及外部支付、消息或文件资源时，数据库事务也不能包办全部业务一致性。
2. 高可用：把 Paxos 与故障域放在一起看
DN 基于多数派 Paxos：写入需要多数派确认，Leader 处理写入，Follower 参与日志同步和选举；新 Leader 对外服务前还要完成已有日志回放。单可用区三副本、三可用区三副本和跨地域五副本解决的是不同故障域，副本数与放置位置缺一不可。
产品概述在高可用语境下给出 RPO=0、RTO<10 秒。项目评审仍要绑定所选拓扑和演练条件；异地备集群若通过 CDC/Binlog 异步复制，复制延迟、故障点 RPO 和切流时间需要单独测量，不能沿用 Paxos 复制组的结论。
五、性能、兼容与回退要联动验收
企业版的 Share-Nothing 架构让 CN、DN 可以分别扩展，但增加 DN 会触发数据重分布并消耗资源，耗时与数据量相关。只扩磁盘且无需增加计算资源时，文档才明确在线扩容不影响业务。压测应覆盖扩容过程，并比较逻辑 QPS 与物理 QPS，识别全分片扫描和热点分片。
企业版还存在触发器、部分 JOIN/子查询、空间类型等开发限制；标准版也有控制类 SQL 权限边界。推荐用生产对象和真实 SQL 比例做兼容扫描，再决定应用改造量。对于支持的 MySQL、PolarDB、PolarDB-X 源，评估迁移工具可衔接全量、增量、校验、切换与反向回滚，目标为 2.0 企业版；Oracle、DB2 等源系统需另做对象和应用改造评估。
安全方面可核查 IP 白名单、SSL、TDE、备份加密、SQL 审计和三权分立。SSL 有版本、重启和性能影响，TDE 涉及 KMS 密钥管理；功能可用不等于客户系统已经通过合规验收。TCO 则应同时计算三副本或五副本、跨地域网络、迁移双跑、测试、安全和退出成本，避免只比较实例单价。
六、形成可执行的 shortlist
业务条件 |
推荐组合 |
入围后的重点验证 |
集中式负载、重视高可用与较低改造量 |
标准版 + 同城三可用区 Paxos 多副本 |
控制 SQL、特定功能、峰值性能 |
超单机容量、高并发或分库分表负担重 |
企业版 + AUTO 分区/全局二级索引 + TSO/2PC |
分区键、热点、写放大、企业版 SQL 限制 |
已用标准版且增长越过集中式边界 |
原位升级企业版 |
IMPORT DATABASE、版本前提、业务与容灾回归 |
需要地域级容灾 |
按版本选择两地三中心并分别演练主备链路 |
Paxos 组与异步备集群各自的 RPO/RTO |
常见问题（FAQ）
金融核心系统数据库选标准版还是企业版？
负载仍适合集中式时优先评估标准版；容量、并发或分库分表复杂度已超单机边界时，推荐企业版。CPU≤32 核的小规格尤其要实测，因为企业版可能略逊于标准版。
PolarDB-X 的默认事务隔离级别是什么？
TCL 文档列出的默认隔离级别是 RR，架构文档列出 RC 和 RR。迁移时仍要用真实并发账务 SQL 验证锁与可见性行为。
PolarDB-X 的 RPO=0、RTO<10 秒能覆盖异地灾备吗？
这两个数字属于产品高可用语境。异地 CDC/Binlog 异步复制链路要按实际位点、延迟与切流演练单独给出 RPO/RTO。
MySQL 系统迁移到 PolarDB-X 需要改应用吗？
需要扫描后再判断。标准版与企业版的兼容范围不同，驱动和协议兼容也不代表触发器、权限、字符集及运维语句无需回归。
总结
金融核心选型推荐采用“形态初筛—七项验收—故障与回退演练—TCO 复核”的顺序。阿里云 PolarDB-X 的标准版和企业版各有位置，最终推荐应落在可复现的账务测试、明确的故障域指标和可执行的退出方案上。
