核心原则：先定义业务需求，再选架构路线，最后挑选产品；不要盲目追求分布式、不要只看跑分、不要只看品牌名气。
整体流程：业务画像梳理 → 架构路线抉择（集中式 / 分布式 / 专用库）→ 多维度打分评估 → POC 实测验证 → 成本 & 风险评审。
一、第一步：梳理你的业务基线（选型输入清单）
先把下面信息整理完整，否则所有对比都是空谈
1）业务负载类型
2）规模指标
当前数据量、未来 3 年预估数据量（TB/PB）
QPS/TPS 峰值、读写比例
单表最大数据量（重点！单表超千万、上亿是分水岭）
3）存量迁移背景
原有数据库：Oracle / MySQL / PostgreSQL / SQLServer
迁移最大成本往往不是授权费，而是SQL 改写、存储过程、函数、触发器适配成本
4）硬性约束
信创要求：是否进入信创目录、国产芯片（海光 / 鲲鹏 / 飞腾）、麒麟 / 统信操作系统适配、密评 / 等保 4 级
部署环境：物理机、虚拟机、容器 K8s、私有云、公有云
容灾要求：主备、双活、两地三中心、RPO=0、RTO 要求
团队能力：有无专职 DBA、能否维护复杂分布式集群
合规限制：是否要求内核自主可控、禁止开源二次封装产品
二、第二步：架构路线二选一（最重要分水岭）
路线 A：集中式数据库（主备 / RAC 集群）
代表产品：达梦 DM8、人大金仓 KingbaseES、GBase 8s、openGauss 集中式
✅适合场景
数据量＜10TB、单表可控、并发中等
Oracle/PG 存量系统迁移、大量存储过程、复杂事务
政务、能源、央企传统业务、信创替代
运维人力有限，不想维护复杂分布式集群
❌不适合：持续暴涨、单表持续膨胀、需要无限水平扩容
优势：架构简单、延迟低、分布式事务痛点少、运维简单、迁移成本低
路线 B：原生分布式 NewSQL
代表产品：OceanBase、TiDB、GaussDB 分布式、TDSQL、GoldenDB
✅适合场景
数据量 10TB~PB 级、单表上亿、业务持续增长
高并发互联网、金融核心账务、跨地域多中心部署
需要在线弹性扩容、不希望手动分库分表
❌不适合：简单小型系统，小业务强行上分布式会大幅提升运维复杂度、增加网络延迟
重要提醒：数据量大≠必须分布式；可以优先方案：集中式 + ShardingSphere 分库分表 作为折中方案
路线 C：专用数据库（不要拿通用库硬扛）
实时数仓 OLAP：StarRocks、SelectDB (Doris)、GBase8a
时序数据：TDengine
向量数据库：Milvus、Vearch（AI 检索场景）
三、主流通用国产数据库定位速览（OLTP 为主）
四、第三步：多维度量化评估清单（POC 招标直接复用）
1. 兼容性（迁移成本权重最高，30%）
SQL 语法、内置函数、存储过程、触发器、游标兼容性
JDBC/ODBC 驱动、MyBatis、ORM 框架适配
迁移工具能力：原库 DDL/DML 自动转换、语法错误识别
避坑：厂商宣称 “完全兼容” 均是语法兼容，复杂 PL/SQL 一定要拿真实业务脚本实测！
2. 自主可控与信创合规（政企项目一票否决项，20%）
是否列入信创数据库目录；内核完全自研还是基于开源改造
国产 CPU：海光、鲲鹏、飞腾、龙芯适配认证
操作系统：麒麟、统信、欧拉适配
安全能力：强制访问控制、透明加密、审计、等保、密评支持
3. 性能与稳定性（20%）
不要只看峰值 TPS，重点测试：
持续压测下性能抖动、P95/P99 延迟
故障注入测试：主节点宕机、磁盘故障、网络抖动，验证 RTO/RPO
分布式场景：跨分片事务性能、Join 查询表现
混合读写场景是否存在资源争抢
4. 高可用、容灾方案（10%）
支持架构：一主多备、共享存储集群、双活、两地三中心；确认同步模式（同步复制 / 异步），能否做到 RPO=0
5. 运维生态与工具链（10%）
可视化运维平台、慢 SQL 分析、监控告警、自动备份恢复
数据同步工具 DTS（和原有数据库双向同步，用于灰度迁移）
巡检、故障诊断能力；是否支持 Prometheus/Grafana 可观测
6. 商业服务与 TCO 总成本（10%）
授权模式：按 CPU、节点、容量、永久授权 / 订阅制
原厂技术支持：本地驻场、响应 SLA、能否提供内核级 bug 修复
培训成本、DBA 人才招聘难度（TiDB 社区人才多；传统商用库人才较少）
⚠️TCO 不止软件费用：硬件升级、迁移改造人力、长期运维人力都要算进去。
五、典型场景快速选型建议
Oracle 存量系统、政务 / 能源央企信创替换、大量存储过程
优先：达梦 DM8 / 人大金仓 KingbaseES（集中式）
MySQL 存量、互联网业务、未来数据持续增长、希望免分库分表
优先：TiDB；金融核心高并发可选 OceanBase
银行 / 证券核心交易系统，强一致、多中心容灾
优先：OceanBase、GoldenDB
PostgreSQL 存量业务、公安、医保平台
优先：人大金仓 KingbaseES
实时报表、数据大屏、海量数据 BI 分析（OLAP）
不要使用 OLTP 数据库，直接选 StarRocks / SelectDB
小型内部管理系统、并发低、数据量不大
优先集中式，避免上分布式增加负担
六、选型避坑清单（高频踩坑点）
❌ 盲目跟风分布式：小规模系统强行分布式，运维成本翻倍
❌ 只看 PPT 性能指标，不做真实业务 POC 压测
❌ 忽视兼容性测试，上线后发现大量 SQL 需要重写，项目延期
❌ 只评估数据库内核，忽略配套工具：迁移工具、监控、DTS 同步
❌ 不调研厂商服务能力，遇到疑难问题无法内核级修复
❌ 混淆 “开源可用” 和 “生产可用”，开源版缺少企业级技术支持
❌ HTAP 万能论：单一数据库同时承载核心交易 + 大规模分析，极易出现资源争抢，大中型项目建议交易库 + 独立 OLAP 库分离部署
七、标准落地实施步骤
输出业务需求规格文档，确定架构路线（集中 / 分布式）
筛选 2~3 款候选产品
搭建 POC 测试环境，导入真实业务 SQL 与数据，完成兼容性、性能、故障演练
成本测算 + 风险评估
先选择非核心业务试点运行 3~6 个月
试点稳定后，灰度迁移核心业务，保留回滚方案