大家好，我是数据库小学妹。
上篇聊了国产数据库怎么从三四十款里筛到两三个，今天换个角度，聊一个更基础的问题：你的业务到底该用哪类数据库？很多团队做数据库选型，上来就纠结"MySQL还是PostgreSQL""OceanBase还是金仓KES"。其实第一步应该问的不是"选哪个产品"，而是"选哪类数据库"。关系型、文档型、键值型、列式分析......选错了类型，后面再换产品代价就大了。
今天这篇文章，就用五个维度帮你想清楚数据库选型的底层逻辑。
数据库选型的核心：不是选产品，是选类型
在聊具体怎么选之前，先搞清楚一件事：数据库选型不是选"最强"的那个，是选"最合适"的那个。我见过太多团队犯同一个错：上来就比性能跑分。TPS高不高？QPS够不够？这些当然重要，但只是一部分。
一套完整的数据库选型决策，要回答五个问题：
- 你的数据长什么样？
- 你的业务场景是什么？
- 你需要多高的可用性？
- 你有没有合规要求？
- 你的总拥有成本能承受多少？
这五个问题，就是我总结的五维选型框架。下面一个一个拆。
数据库选型第一维：数据类型决定数据库类型
数据库选型第一步不是看产品，是看数据。
数据是结构化的、半结构化的，还是非结构化的？这基本决定了你该用哪一类数据库。注意，这里说的是"哪一类"，不是"哪一个"------先定大类，再选产品，顺序不能反。
| 你的数据长什么样 | 该用哪类数据库 | 典型场景 | 选错的代价 |
|---|---|---|---|
| 格式固定、关系明确（订单、账户、财务流水） | 关系型（RDBMS） | 交易系统、ERP、CRM | 用NoSQL存结构化数据，后期加约束成本极高 |
| 字段随时变、嵌套结构（日志、行为轨迹、配置） | 文档型/宽列型 | 内容管理、用户行为分析 | 用关系型存JSON，三天两头ALTER TABLE |
| 简单键值对、高频读写（缓存、会话、排行） | 键值型/内存型 | 会话管理、热点缓存 | 用磁盘数据库做缓存，延迟差两个数量级 |
| 时间序列、写入量巨大（传感器、监控指标） | 时序型/列式型 | IoT、设备监控 | 用行存数据库扛海量写入，索引维护成本爆炸 |
| 需要遍历关系网络（社交图谱、推荐链路） | 图数据库 | 社交网络、反欺诈 | 用关系表递归JOIN，跳数一多查询就废了 |
| 二进制大文件（图片、视频、音频） | 对象存储+元数据索引 | 媒体管理、CDN | 把文件直接塞数据库，存储和IO成本失控 |
我见过一个项目，把用户行为日志硬塞进MySQL，表结构三天两头ALTER，业务方投诉不断。后来换MongoDB才解决。问题不在MySQL不好，而是数据类型选错了。
数据库选型第一步：对照上面这张表，搞清楚你的数据属于哪一类，再决定用哪类数据库。如果一个系统里多种数据类型都有（很常见），那就需要多种数据库配合------这在第二维里详细讲。
数据库选型第二维：业务场景决定产品打法
第一维帮你定了数据库大类，但同类数据库里产品差异也很大。MySQL和PostgreSQL都是关系型，适用场景却不同。到了这一维，才开始选具体产品。
不同场景对数据库的要求差很多。下面几个最常见的场景，快速对号入座。
电商/交易系统
核心需求是强一致性和事务支持。每笔订单涉及库存扣减、支付记录、物流状态，任何一个环节出错都不行。
这类场景首选关系型数据库。MySQL生态成熟，社区资料多，中小团队上手快。PostgreSQL功能更丰富，复杂查询能力强，适合业务逻辑复杂的系统。手头有大量Oracle存量代码要迁移的话，KES的Oracle兼容度在国产数据库里算比较高的，PL/SQL存储过程的兼容性经过多个金融、政务项目验证，迁移改造成本可控。
同一个业务需求，不同数据库的执行策略可能完全不同。选型时建议拿你最复杂的查询SQL跑一下执行计划对比：
sql
-- MySQL：EXPLAIN看执行计划
EXPLAIN ANALYZE
SELECT o.order_id, o.total_amount, u.username
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.create_time >= '2026-01-01'
AND o.status = 'paid'
ORDER BY o.total_amount DESC
LIMIT 100;
-- PostgreSQL：EXPLAIN (ANALYZE, BUFFERS) 更详细
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT o.order_id, o.total_amount, u.username
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.create_time >= '2026-01-01'
AND o.status = 'paid'
ORDER BY o.total_amount DESC
LIMIT 100;
-- 关注点：走了索引还是全表扫描？JOIN算法是Nested Loop还是Hash Join？
-- 同样的表结构和数据，MySQL可能走索引，PG可能走全表扫描，结果差10倍。内容管理/用户行为分析
数据结构多变，字段经常增减。MongoDB的文档模型处理这种场景比较顺手，配合Elasticsearch做全文检索，是一套大量项目验证过的组合。
缓存/实时排行榜
Redis几乎是唯一答案。内存级读写延迟，支持丰富的数据结构。做排行榜用Sorted Set，做会话存储用Hash，用过的都说香。
海量时序数据/IoT
设备监控、传感器数据这类写入量巨大的场景，Cassandra和HBase都是成熟方案。之前接触过一个电力监控项目，用KES做时序数据存储，不用额外搭一套时序数据库，少运维一个组件，对小团队来说省心不少。不过这种方案适合数据量中等、查询模式相对固定的场景，如果你的物联网平台日均写入量上了百亿级，还是建议评估专用时序数据库。
大数据分析/OLAP
ClickHouse在实时分析场景表现突出，列式存储加向量化引擎，聚合查询速度快。Hive适合离线批处理。选型时要看你的分析是实时的还是离线的，延迟要求不同，选择差很多。
数据库选型最忌讳"一刀切"。一个业务系统里，往往需要多种数据库配合使用。核心交易用关系型，搜索用ES，缓存用Redis，日志用MongoDB。这才是现代应用的常态。
多数据库混用有一个隐藏风险：数据同步。MySQL和ES之间的同步延迟、Redis缓存和主库之间的数据一致性，这些问题在选型阶段就要想清楚。别等上线了才发现用户改了数据但搜出来还是旧的。
数据库选型第三维：高可用架构选错了背锅的是你
数据库选型不能只看单机性能，还得看它能搭什么架构。
我之前有个项目用的单机数据库，一次磁盘故障导致业务停了两小时。从那以后学乖了：高可用方案必须在选型阶段就考虑清楚。
常见的高可用架构分几档：
| 架构类型 | 适用场景 | 特点 |
|---|---|---|
| 主从复制/主备 | 一般业务系统 | 故障自动切换，实现简单 |
| 读写分离 | 报表、BI场景 | 写走主库，读分发到只读节点 |
| 共享存储多写（RAC） | 高并发OLTP | 多节点同时对外服务，可用性极高 |
| 两地三中心 | 金融级容灾 | 双中心加异地灾备，RPO=0 |
MySQL的主从复制方案最成熟，社区工具丰富。PostgreSQL的流复制和逻辑复制也很稳定。如果需要共享存储级别的多写能力，KES的RAC方案支持2到8个节点同时对外服务，在金融和政务场景有多年运行经验。
选型时有个常见误区：数据量不大就上分布式集群。我见过一个团队，业务并发其实不高，硬上了分布式架构，日常运维把人拖垮了。后来回退到主备集群，省心省力。
架构选型的原则是：匹配业务规模，不是越复杂越好。
数据库选型第四维：信创合规是及格线不是加分项
这两年信创替代推进得很快，数据库选型多了一个绕不开的维度：合规性。
政务、金融、能源、交通这些行业，信创不是"能不能做"的问题，是"什么时候做"的问题。选型时忽略了合规要求，整个项目可能推倒重来。
信创选型主要看三件事：数据库内核是否完全自研（信创招标的硬门槛）、安全认证是否齐全（等保四级、EAL4+、国密SM2/SM3/SM4）、能不能跑在国产芯片和操作系统上（鲲鹏、飞腾、统信、麒麟等适配情况）。
KES、OceanBase、TiDB、GaussDB等国产数据库在信创适配上都做了不少工作。如果你的系统目前跑在Oracle上，迁移成本是最大的变量。存储过程、触发器、自定义函数，改起来费时费力。我迁移过的几个项目，KES对Oracle语法的兼容度整体不错，PL/SQL代码大概95%以上不用动，剩下主要是存储过程里调外部接口和部分高级分析函数那块，需要针对性改写。选型时建议先用实际SQL跑一轮兼容性测试，别光看宣传材料。下面是我常用的一个快速兼容性摸底方法：
sql
-- Oracle兼容性快速摸底：跑一遍你项目里最常用的三类对象
-- 1. 存储过程（重点看EXCEPTION处理、DBMS_包调用）
CREATE OR REPLACE PROCEDURE sp_test_compat AS
v_count NUMBER;
BEGIN
SELECT COUNT(*) INTO v_count FROM user_tables;
DBMS_OUTPUT.PUT_LINE('Tables: ' || v_count);
EXCEPTION
WHEN OTHERS THEN
RAISE_APPLICATION_ERROR(-20001, SQLERRM);
END;
-- 2. 分析函数（ROW_NUMBER、LAG/LEAD、窗口排序）
SELECT order_id, user_id, amount,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY amount DESC) AS rn,
LAG(amount, 1) OVER (ORDER BY create_time) AS prev_amount
FROM orders
WHERE create_time >= ADD_MONTHS(SYSDATE, -3);
-- 3. 同义词和DBLink（跨库查询场景）
CREATE SYNONYM remote_orders FOR orders@dblink_prod;
SELECT * FROM remote_orders WHERE ROWNUM <= 100;跑完之后统计：能直接执行的、需要小幅改写的、完全不兼容的各占多少比例，这个数字比任何厂商的兼容性报告都真实。
关于国产数据库选型的详细方法论（四步筛选框架、30款产品对比、行业场景推荐），昨天的文章已经做过系统拆解，这里不再重复。没看过的朋友可以进主页翻翻上一篇。
数据库选型第五维：算清五年TCO再做决定
数据库选型最容易被忽视的维度是成本。很多人只算软件授权费，不算隐性成本。
总拥有成本至少包含四块：
| 成本项 | 说明 |
|---|---|
| 软件授权费 | 开源免费还是商业授权，按节点还是按核心收费 |
| 硬件成本 | 分布式架构需要更多服务器，集中式对硬件要求相对低 |
| 迁移改造成本 | 存储过程改写、应用适配、数据迁移，这是大头 |
| 运维人力成本 | 分布式架构需要专业DBA团队，集中式运维门槛相对低 |
我之前一个项目，软件费用只占三成，人力改造占了七成。选型报告里只写了"授权费XX万"，领导觉得挺便宜。结果迁移改造花了半年，人力成本远超预期。
给大家一个实际的五年TCO估算公式，选型时直接套：
text
五年TCO = 授权费 + 硬件成本 + 迁移改造成本 + 运维人力成本
举个真实场景（200并发、3节点集群、五年周期）：
┌──────────────┬─────────────┬──────────────┬──────────────┐
│ 成本项 │ 开源MySQL │ Oracle │ KES │
├──────────────┼─────────────┼──────────────┼──────────────┤
│ 软件授权（5年） │ 0 │ ≈180万 │ ≈45万 │
│ 硬件/云资源 │ ≈30万 │ ≈30万 │ ≈30万 │
│ 迁移改造人力 │ 0（已是MySQL） │ 0（已是Oracle） │ ≈25万（PL/SQL改写）│
│ 运维DBA（5年） │ ≈50万（自建） │ ≈40万（含厂商支持）│ ≈35万 │
├──────────────┼─────────────┼──────────────┼──────────────┤
│ 五年TCO合计 │ ≈80万 │ ≈250万 │ ≈135万 │
└──────────────┴─────────────┴──────────────┴──────────────┘
注：以上为估算示例，实际费用因采购规模、行业集采政策而异这张表的教训很清楚：Oracle的TCO大头在授权费，KES的TCO大头在迁移改造，MySQL的TCO大头在运维人力。不同数据库的成本结构完全不同，只看授权费是最大的选型陷阱。
开源数据库（MySQL、PostgreSQL）授权费为零，但需要自己搭运维团队。商业数据库（Oracle、SQL Server）有完善的技术支持，但授权费高昂。国产数据库的定价相对灵活，KES在政务和电力行业有大量集采案例，价格体系比较透明。
云数据库是另一个选择。按需付费，不用操心硬件。但长期使用的成本要仔细算，别被"首月免费"的促销忽悠了。
数据库选型时建议做一张五年TCO对比表。把授权费、硬件、人力、迁移成本全部算进去，数字会更真实。
数据库选型横评：九款主流产品一张表看清
说了这么多维度，用一张表帮你快速建立全局认知。
| 数据库 | 类型 | 核心优势 | 适用场景 | 社区/生态规模 | 注意事项 |
|---|---|---|---|---|---|
| MySQL | 关系型 | 生态成熟、易上手 | 中小型Web应用、互联网业务 | GitHub 60k+ Stars，全球装机量第一 | 扩展能力有限，复杂事务需评估 |
| PostgreSQL | 关系型 | 功能丰富、扩展性强 | 复杂查询、GIS、数据分析 | GitHub 17k+ Stars，扩展插件超千款 | 上手门槛比MySQL稍高 |
| Oracle | 关系型 | 企业级能力、极致性能 | 金融核心、超大规模OLTP | 全球商业数据库市场份额第一 | 授权费高昂，不满足信创合规 |
| KES | 关系型 | Oracle高兼容、信创齐全 | Oracle替代、政务、金融 | 信创集采覆盖率领先，国内装机量稳步增长 | Oracle迁移需评估PL/SQL改造量；选型时建议用实际业务SQL跑一轮兼容性测试 |
| MongoDB | 文档型 | 灵活的文档模型 | 内容管理、日志分析 | GitHub 26k+ Stars，DB-Engines文档型排名第一 | 事务支持有版本限制 |
| Redis | 键值型 | 内存级低延迟 | 缓存、会话、排行榜 | GitHub 67k+ Stars，全球缓存首选 | 数据持久性需配合策略 |
| ClickHouse | 列式分析 | 实时OLAP性能突出 | 广告分析、实时看板 | GitHub 40k+ Stars，OLAP增速最快 | 不适合事务处理 |
| TiDB | 分布式 | 水平扩展、MySQL兼容 | 大规模OLTP、HTAP | GitHub 38k+ Stars，PingCAP主导 | 运维复杂度较高 |
| OceanBase | 分布式 | 金融级高可用 | 金融交易、高并发场景 | 蚂蚁集团开源，金融核心系统验证 | 部署运维需专业团队 |
这张表不是让你直接选，是帮你建立第一轮筛选范围。具体选哪个，还得回到前面的五维框架里逐项评估。
数据库选型决策流程：四个分支对号入座
框架有了，横评也有了，最后给一个可以直接对号入座的决策流程。
text
你的原数据库是什么？
|
+-- Oracle --> 有信创替代要求？
| +-- 是 --> KES（PL/SQL兼容度高，迁移改造成本低）
| +-- 否 --> 看预算和生态需求
|
+-- MySQL --> 数据量和并发在什么级别？
| +-- 中小规模 --> 继续用MySQL，成熟稳定
| +-- 需要水平扩展 --> 考虑TiDB或KES分布式Sharding方案
|
+-- 全新项目，从零开始
| +-- 政务/金融/能源 --> 优先评估国产数据库（KES/OceanBase/TiDB）
| +-- 互联网业务 --> MySQL/PostgreSQL + Redis + ES组合
| +-- 大数据分析 --> ClickHouse/Hive + 数据仓库方案
|
+-- 多种数据库混合使用
+-- 确定核心交易用什么 --> 再搭配缓存、搜索、分析组件数据库选型验证三步法：框架选完还要跑一遍
上面的框架帮你缩小范围，但最终拍板之前，一定要做验证。我见过太多团队框架分析得头头是道，结果上线就翻车，原因就是跳过了验证环节。
第一步：需求对标。 把五维框架里你最在意的3个需求列出来，逐一对标候选数据库。比如你最在意Oracle兼容、信创合规、运维成本，那就把这三个维度的评估结果拉出来横向比较。不要被厂商的全面评测迷惑，聚焦你自己的核心需求。
第二步：POC实测。 用自己的业务数据和真实SQL负载搭测试环境，至少跑三轮验证：
sql
-- POC验证模板：三类核心SQL各跑一轮
-- 第一轮：功能性验证（你的存储过程、分析函数能不能跑）
-- 第二轮：性能基准（核心业务SQL的TPS和响应时间）
-- 第三轮：故障模拟（手动杀主节点，观察切换耗时和数据一致性）
-- 性能基准示例：统计核心查询的响应时间分布
SELECT query_text,
AVG(execution_time_ms) AS avg_ms,
PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY execution_time_ms) AS p95_ms,
COUNT(*) AS exec_count
FROM pg_stat_statements -- 或对应的性能视图
WHERE query_text LIKE '%orders%'
GROUP BY query_text
ORDER BY avg_ms DESC;第三步：灰度上线。 先在非核心业务跑一个月，观察稳定性和运维成本。没问题再切核心业务。这一步看起来慢，但比上线后回退快十倍。
数据库选型最容易翻车的四个细节
数据库选型最容易踩的坑，最后说几条。每一条都是真金白银换来的教训。
不同类型数据库混用时忘了管数据同步。 现代应用很少只用一种数据库。MySQL做核心交易，Redis做缓存，ES做搜索，MongoDB存日志，这种组合很常见。但选型时往往只关注单个数据库的能力，忽略了数据同步的一致性和延迟。我有个项目，MySQL和ES之间的数据同步延迟了5秒，用户刚改完昵称搜不到自己，投诉量涨了三倍。
同一段SQL换了数据库跑出不同结果。 不同数据库的优化器策略、索引机制、锁粒度差异很大。迁移完成后建议对核心业务SQL做一轮执行计划检查。我遇到过一个案例，Oracle里跑得好好的窗口函数，换到另一款数据库后执行计划走了全表扫描，查询时间从200毫秒飙到12秒。该加索引的加索引，该改写的改写。分库分表场景更要注意，同样的分片键和路由策略，不同数据库中间件的行为可能完全不同：
sql
-- 分库分表路由示例：按用户ID取模分4个库
-- 不同中间件的写法差异很大，迁移时必须逐条验证
-- ShardingSphere写法（YAML配置 + SQL透传）
-- application.yml:
-- spring.shardingsphere.rules.sharding.tables.orders.database-strategy.standard.sharding-column=user_id
-- spring.shardingsphere.rules.sharding.tables.orders.database-strategy.standard.sharding-algorithm-name=db_mod
-- SQL直接写，中间件自动路由：
SELECT * FROM orders WHERE user_id = 10086 AND create_time >= '2026-01-01';
-- 但如果跨分片查询，不同中间件的处理策略完全不同：
-- 跨4个分片聚合排序，结果可能不一致
SELECT user_id, SUM(total_amount) AS total
FROM orders
WHERE create_time >= '2026-01-01'
GROUP BY user_id
ORDER BY total DESC
LIMIT 10;
-- 迁移后务必对比：分片路由是否一致、聚合结果是否相同、排序是否稳定只看跑分不跑POC。 TPC-C跑分高不代表你的业务跑得快。数据库在实验室环境和真实生产环境下的表现差距可以很大。选型时一定要用自己的业务数据做POC测试，别被厂商的benchmark数据忽悠。
只算授权费不算总成本。 前面说过了，迁移改造和运维人力才是大头。做一张五年TCO对比表，别被表面的"免费"或"便宜"误导。我之前一个项目，软件费用只占三成，人力改造占了七成。
写在最后
数据库选型没有标准答案。MySQL好用的场景，Oracle未必合适。分布式架构听起来高级，集中式可能更省心。
回到业务本身。你的数据类型是什么？并发量级多大？有没有信创合规要求？团队能驾驭什么架构？这五个维度想清楚，方向就不会偏。
说一千道一万，不如自己搭一套测试环境跑一遍。真实场景验证比看一百篇评测文章都管用。如果非要我给一句话建议：有Oracle迁移或信创硬性要求的项目，KES值得放进候选名单认真跑一轮POC。实测过的才有发言权。
你目前在做什么项目？用的什么数据库？评论区聊聊你的情况，咱们一起分析。
我是数据库小学妹，咱们下篇见。
本文数据来源：墨天轮中国数据库流行度排行榜、各厂商官方文档及公开技术白皮书。测试数据参考行业实测报告，实际表现因部署环境而异。文中提及的产品仅为技术参考，实际选型应结合具体业务需求综合评估。