数据库选型决策：MySQL、PostgreSQL、NoSQL的实战选择

问题引入：一个真实的选型困境

去年我参与了一个电商平台的重构项目，面对的第一个技术决策就是数据库选型。团队内部争论不休：

后端团队："我们用MySQL吧，熟悉、社区活跃、招聘容易"
架构师："PostgreSQL功能更强大，支持JSON、全文搜索"
产品经理："听说MongoDB开发效率高，要不要试试？"
运维同学："Redis必须要，缓存不能少"

最终我们采用了混合架构，但过程中踩了不少坑。今天我就以这个项目为例，分享数据库选型的完整决策过程。

现象描述：选型失误的代价

案例1：盲目追求新技术

我们最初在商品详情页使用了MongoDB存储商品信息，理由是"schema灵活，适合商品属性多变"。结果上线后发现：

查询性能差：复杂的商品筛选查询响应时间超过2秒
聚合困难：统计报表需要大量的应用层处理
运维复杂：备份、监控、性能调优都是新挑战

最终方案：迁移回MySQL，使用JSON字段存储可变属性，核心字段保持关系型结构。

案例2：忽视数据一致性

订单系统最初使用了MySQL主从架构，但为了"性能"将读请求全部路由到从库。结果：

用户下单后立即查看订单，显示"订单不存在"
库存扣减后查询，显示库存未减少
客服系统查询不到最新订单状态

根本原因：主从延迟导致的数据不一致。

原因分析：数据库特性深度剖析

关系型 vs 非关系型数据库

特性	关系型数据库 (MySQL/PostgreSQL)	非关系型数据库 (MongoDB/Redis)
数据模型	表结构，严格Schema	文档/键值，灵活Schema
事务支持	ACID完整支持	部分支持或最终一致性
查询能力	SQL强大，支持复杂JOIN	查询相对简单，聚合能力弱
扩展性	垂直扩展为主，分库分表复杂	水平扩展友好
适用场景	事务性强，关系复杂的业务	高并发读写，数据结构灵活

MySQL vs PostgreSQL 深度对比

1. 功能特性

MySQL 优势：
✓ 社区庞大，文档丰富
✓ 主从复制成熟
✓ 云服务商支持好
✓ 招聘相对容易
✓ 性能优化工具多

PostgreSQL 优势：
✓ 标准SQL支持更完整
✓ 支持复杂数据类型（数组、JSON、地理信息）
✓ 扩展性强（PostGIS、全文搜索）
✓ 查询优化器更智能
✓ 并发性能更好（MVCC实现）

2. 性能对比（基于sysbench测试）

测试场景	MySQL 8.0	PostgreSQL 14	结论
纯写入 (write_only)	15,000 TPS	12,000 TPS	MySQL略胜
读写混合 (oltp_read_write)	8,500 TPS	9,200 TPS	PostgreSQL略胜
复杂查询	基准100%	120-150%	PostgreSQL优势明显
并发连接 (500+)	性能下降30%	性能下降15%	PostgreSQL更稳定

NoSQL数据库选型矩阵

数据库	数据模型	最佳场景	不适用场景
MongoDB	文档	内容管理、产品目录、日志存储	强事务、复杂关联查询
Redis	键值	缓存、会话、实时排行榜	持久化存储、复杂查询
Elasticsearch	搜索引擎	全文搜索、日志分析	事务性数据、频繁更新
Cassandra	宽列	时序数据、物联网	复杂查询、强一致性
Neo4j	图	社交网络、推荐系统	通用数据存储

解决方案：电商系统数据库选型实战

我们的混合架构设计

┌─────────────────────────────────────────────────────────┐
│                    电商系统数据库架构                      │
├─────────────────────────────────────────────────────────┤
│  MySQL (主)                                             │
│  ├── 订单库 (order_db)      → 核心业务，强一致性         │
│  ├── 库存库 (inventory_db)  → 高并发扣减                │
│  ├── 用户库 (user_db)       → 用户信息、账户            │
│  └── 支付库 (payment_db)    → 金融级数据                │
├─────────────────────────────────────────────────────────┤
│  PostgreSQL                                             │
│  └── 商品库 (product_db)    → 复杂查询、JSON属性        │
├─────────────────────────────────────────────────────────┤
│  MongoDB                                                │
│  └── 日志库 (log_db)        → 操作日志、埋点数据        │
├─────────────────────────────────────────────────────────┤
│  Redis                                                  │
│  ├── 会话缓存 (session)     → 用户登录状态              │
│  ├── 商品缓存 (product)     → 热点商品数据              │
│  ├── 库存缓存 (stock)       → 实时库存扣减              │
│  └── 排行榜 (ranking)       → 销量排行                  │
├─────────────────────────────────────────────────────────┤
│  Elasticsearch                                          │
│  └── 商品搜索 (search)      → 全文搜索、筛选            │
└─────────────────────────────────────────────────────────┘

选型决策矩阵

业务模块	数据特点	选型	理由
订单系统	强事务、不可丢失	MySQL	ACID保障，成熟稳定
商品系统	复杂查询、属性多变	PostgreSQL	JSON支持，查询优化器强
库存系统	高并发、强一致	MySQL + Redis	数据库持久化 + 缓存抗并发
用户系统	关系复杂、事务多	MySQL	成熟方案，生态完善
搜索系统	全文检索、高查询	Elasticsearch	专业搜索能力
日志系统	写入量大、无事务	MongoDB	高写入，schema灵活
缓存层	高性能、临时数据	Redis	内存操作，性能极致

实施步骤：选型评估流程

第一步：需求分析清单

□ 数据量预估（当前/1年后/3年后）
□ 并发量预估（QPS/TPS峰值）
□ 事务要求（强一致/最终一致）
□ 查询复杂度（简单CRUD/复杂分析）
□ 数据关系（独立/高度关联）
□ 扩展需求（垂直/水平扩展）
□ 团队技术栈（熟悉度/学习成本）
□ 运维能力（监控/备份/调优）

第二步：POC验证

// 示例：对候选数据库进行性能测试
@Component
public class DatabaseBenchmark {
    
    @Autowired
    private List<DataSource> candidateDataSources;
    
    public BenchmarkReport runBenchmark() {
        BenchmarkReport report = new BenchmarkReport();
        
        // 1. 写入性能测试
        for (DataSource ds : candidateDataSources) {
            long startTime = System.currentTimeMillis();
            // 执行10000次插入
            performWriteTest(ds, 10000);
            long writeTime = System.currentTimeMillis() - startTime;
            report.addWriteResult(ds.getName(), writeTime);
        }
        
        // 2. 查询性能测试
        for (DataSource ds : candidateDataSources) {
            long startTime = System.currentTimeMillis();
            // 执行复杂查询
            performComplexQueryTest(ds);
            long queryTime = System.currentTimeMillis() - startTime;
            report.addQueryResult(ds.getName(), queryTime);
        }
        
        // 3. 并发测试
        for (DataSource ds : candidateDataSources) {
            performConcurrencyTest(ds, 100); // 100并发
        }
        
        return report;
    }
}

第三步：成本评估

成本项	MySQL	PostgreSQL	MongoDB	备注
授权费用	免费(GPL)	免费(PostgreSQL License)	免费(SSPL)	企业版另计
硬件成本	中	中	高(内存需求大)	基于相同性能需求
人力成本	低(人才多)	中	中	招聘和培训
运维成本	低(工具多)	中	中	监控、备份、调优
云服务费	低	中	高	阿里云RDS价格对比

效果验证：优化前后的对比

商品详情页性能

指标	优化前(MongoDB)	优化后(PostgreSQL)	提升
平均响应时间	850ms	120ms	85% ↓
P99响应时间	2200ms	280ms	87% ↓
数据库CPU使用率	75%	35%	53% ↓
慢查询比例	12%	0.5%	96% ↓

订单系统稳定性

指标	优化前	优化后	提升
主从延迟	50-200ms	<10ms	95% ↓
数据不一致投诉	15次/天	0次	100% ↓
订单查询成功率	97.5%	99.99%	2.5% ↑

经验总结：数据库选型最佳实践

✅ 应该做的

从业务出发：先理解业务场景，再选择技术
数据驱动：用POC验证替代主观判断
考虑团队：技术栈要与团队能力匹配
预留扩展：设计时考虑未来3年的增长
混合架构：没有银弹，合理组合多种数据库

❌ 不应该做的

盲目追新：不要因为"酷"而选择新技术
过度设计：小业务不需要分布式数据库
忽视运维：开发容易运维难，要考虑长期成本
一刀切：不同模块用不同数据库是常态
忽视一致性：不要为了性能牺牲数据一致性

扩展思考：云原生时代的数据库选型

Serverless数据库趋势

传统数据库 → 云数据库 → Serverless数据库

阿里云PolarDB Serverless
- 自动扩缩容
- 按实际使用付费
- 适合业务波动大的场景

AWS Aurora Serverless
- 自动休眠/唤醒
- 适合开发测试环境
- 成本可降低70%

多模数据库的兴起

TiDB: 兼容MySQL + 分布式 + HTAP
CockroachDB: 兼容PostgreSQL + 全球分布式

优势：
- 减少技术栈复杂度
- 统一运维管理
- 降低学习成本

适用：
- 不想维护多种数据库的团队
- 需要全球分布的业务

读者练习

思考题：你的项目目前使用什么数据库？如果重新选型，你会怎么选择？
实践题：对你负责的一个模块，按照本文的评估矩阵重新评估数据库选型。
挑战题：设计一个支持千万级并发的秒杀系统数据库架构。

进一步学习

《高性能MySQL》- Baron Schwartz
《PostgreSQL实战》- 谭峰
MongoDB官方文档：https://docs.mongodb.com
数据库选型工具：https://db-engines.com

系列下一篇：数据库设计范式与反范式的实战平衡

深度案例分析：金融系统数据库选型

项目背景

某金融科技公司需要构建一个支付清算系统，日均交易量1000万笔，峰值QPS 50000，数据一致性要求极高。

选型过程

阶段一：需求梳理

核心业务需求：
1. 支付交易：强一致性，不可丢失
2. 账户余额：精确计算，并发控制
3. 对账系统：复杂查询，批量处理
4. 风控系统：实时分析，快速响应
5. 日志审计：海量存储，合规要求

非功能性需求：
- 可用性：99.99%
- 延迟：P99 < 100ms
- 数据一致性：强一致性
- 可扩展性：支持10倍增长

阶段二：技术选型对比

数据库	支付交易	账户余额	对账系统	风控系统	日志审计
MySQL	✓✓✓	✓✓✓	✓✓	✓	✓
PostgreSQL	✓✓	✓✓	✓✓✓	✓✓	✓
Oracle	✓✓✓	✓✓✓	✓✓✓	✓✓	✓
TiDB	✓✓	✓✓	✓✓	✓✓✓	✓✓
ClickHouse	✗	✗	✓✓✓	✓✓✓	✓✓✓

阶段三：最终架构

┌─────────────────────────────────────────┐
│           金融支付系统架构               │
├─────────────────────────────────────────┤
│  核心交易层 (MySQL Cluster)             │
│  ├── 支付交易库 - 主从+半同步复制        │
│  ├── 账户余额库 - 分库分表               │
│  └── 资金流水库 - 按月分区               │
├─────────────────────────────────────────┤
│  分析报表层 (ClickHouse)                │
│  ├── 实时风控数据                        │
│  ├── 对账分析数据                        │
│  └── 经营报表数据                        │
├─────────────────────────────────────────┤
│  缓存加速层 (Redis Cluster)             │
│  ├── 热点账户缓存                        │
│  ├── 限流计数器                          │
│  └── 分布式锁                            │
├─────────────────────────────────────────┤
│  日志审计层 (Elasticsearch)             │
│  ├── 操作日志                            │
│  ├── 审计日志                            │
│  └── 安全日志                            │
└─────────────────────────────────────────┘

关键技术决策

决策1：为什么核心交易选择MySQL而非Oracle？

选择MySQL的原因：

成本因素：Oracle授权费用高昂，MySQL免费
自主可控：MySQL开源，可深度定制
人才储备：MySQL人才更容易招聘
云原生支持：主流云厂商对MySQL支持更好

风险缓解措施：

采用MySQL企业级分支Percona Server
引入中间件实现分布式事务
建立完善的监控和备份体系

决策2：为什么引入ClickHouse？

背景问题：

对账查询涉及数亿条记录，MySQL查询超时
风控需要实时分析最近30天交易模式
监管报表生成需要数小时

ClickHouse解决方案：

-- 实时风控查询示例
SELECT 
    user_id,
    count() as transaction_count,
    sum(amount) as total_amount,
    uniq(counterparty) as unique_counterparties
FROM transactions 
WHERE transaction_time > now() - INTERVAL 1 HOUR
GROUP BY user_id
HAVING transaction_count > 100 OR total_amount > 1000000;

性能提升：

对账查询：从30分钟降到10秒
风控分析：从分钟级降到秒级
报表生成：从4小时降到5分钟

实施过程中的挑战

挑战1：数据一致性保障

问题：跨库转账如何保证一致性？

解决方案：

@Service
public class TransferService {
    
    @Autowired
    private TransactionTemplate transactionTemplate;
    
    @Autowired
    private MessageQueue messageQueue;
    
    public void transfer(Long fromAccount, Long toAccount, BigDecimal amount) {
        // 1. 本地事务：扣减转出账户
        transactionTemplate.execute(status -> {
            accountDao.decreaseBalance(fromAccount, amount);
            transactionLogDao.insert(new TransactionLog(...));
            return null;
        });
        
        // 2. 发送消息：异步增加转入账户
        messageQueue.send(new TransferMessage(toAccount, amount));
        
        // 3. 消息消费者处理转入
        @KafkaListener(topics = "transfer")
        public void handleTransfer(TransferMessage msg) {
            transactionTemplate.execute(status -> {
                accountDao.increaseBalance(msg.getToAccount(), msg.getAmount());
                return null;
            });
        }
    }
}

挑战2：热点账户处理

问题：某些大商户账户并发极高，成为瓶颈

解决方案：

1. 缓存优化：账户余额缓存到Redis
2. 异步合并：高频小额交易合并处理
3. 分片策略：按商户ID分片分散压力
4. 读写分离：查询走从库，写入走主库

效果评估

性能指标

指标	目标	实际	达成率
平均响应时间	<100ms	45ms	125%
P99响应时间	<200ms	120ms	167%
系统可用性	99.99%	99.995%	100%
日交易处理能力	1000万	3000万	300%

业务价值

成本节约：相比Oracle方案，年节约授权费500万
效率提升：对账时间从天级降到分钟级
风险控制：实时风控拦截欺诈交易，年减少损失2000万
合规保障：完整审计日志，通过监管检查

数据库选型决策树

开始选型
    │
    ▼
数据一致性要求？
    │
    ├── 强一致性（金融、支付）
    │       └── 关系型数据库
    │           ├── 高并发 → MySQL/PostgreSQL + 分库分表
    │           └── 复杂分析 → Oracle/SQL Server
    │
    └── 最终一致性（互联网应用）
            │
            ├── 数据结构复杂多变？
            │       ├── 是 → MongoDB/DocumentDB
            │       └── 否 → 继续判断
            │
            ├── 需要全文搜索？
            │       ├── 是 → Elasticsearch
            │       └── 否 → 继续判断
            │
            ├── 时序数据？
            │       ├── 是 → InfluxDB/TimescaleDB
            │       └── 否 → 继续判断
            │
            ├── 缓存场景？
            │       ├── 是 → Redis/Memcached
            │       └── 否 → 继续判断
            │
            └── 图关系数据？
                    ├── 是 → Neo4j
                    └── 否 → MySQL/PostgreSQL

常见选型误区与避坑指南

误区1：盲目追求高性能

错误做法：为了极致性能选择内存数据库作为主存储

后果：

数据持久化风险
成本急剧上升
运维复杂度增加

正确做法：

关系型数据库做主存储
内存数据库做缓存加速
根据业务分层选择

误区2：忽视团队能力

错误做法：选择技术先进但团队不熟悉的数据库

后果：

开发效率低下
线上问题频发
人才招聘困难

正确做法：

评估团队技术栈
预留学习成本
渐进式引入新技术

误区3：过度设计

错误做法：初创公司直接使用分布式数据库

后果：

开发成本增加
运维负担加重
资源浪费

正确做法：

单体应用起步
按需演进架构
避免过早优化

误区4：忽视数据迁移成本

错误做法：不考虑历史数据迁移难度

后果：

迁移周期漫长
数据不一致风险
业务中断

正确做法：

提前规划迁移方案
双写过渡
灰度切换

数据库选型评估模板

技术评估维度

维度	权重	MySQL	PostgreSQL	MongoDB	备注
功能满足度	25%	8	9	7	是否满足业务需求
性能表现	20%	8	8	9	基准测试得分
扩展能力	15%	7	7	9	水平扩展支持
运维成本	15%	9	7	6	监控、备份、调优
团队熟悉度	15%	9	6	5	学习曲线
社区生态	10%	9	8	7	文档、工具、支持
加权总分	100%	8.15	7.75	7.25

成本评估模板

# 3年TCO估算（单位：万元）

mysql:
  授权费用: 0
  服务器成本: 
    - 生产环境: 3台 * 5万/年 * 3年 = 45万
    - 测试环境: 2台 * 2万/年 * 3年 = 12万
  人力成本:
    - DBA: 2人 * 30万/年 * 3年 = 180万
    - 开发培训: 10万
  运维工具: 20万
  总计: 267万

postgresql:
  授权费用: 0
  服务器成本: 同MySQL = 57万
  人力成本:
    - DBA: 2人 * 35万/年 * 3年 = 210万  # 人才较贵
    - 开发培训: 20万
  运维工具: 25万
  总计: 312万

mongodb:
  授权费用: 0  # 社区版
  服务器成本: 
    - 生产环境: 6台 * 8万/年 * 3年 = 144万  # 内存需求大
    - 测试环境: 3台 * 3万/年 * 3年 = 27万
  人力成本:
    - DBA: 2人 * 40万/年 * 3年 = 240万  # 专家稀缺
    - 开发培训: 30万
  运维工具: 40万
  总计: 481万

未来趋势展望

云原生数据库

特点：
- 存储计算分离
- 弹性扩缩容
- 按需付费
- 托管运维

代表产品：
- AWS Aurora
- 阿里云PolarDB
- Google Cloud Spanner
- CockroachDB

适用场景：
- 业务波动大
- 运维能力有限
- 快速迭代需求

多模数据库

概念：单一数据库支持多种数据模型

优势：
- 简化技术栈
- 统一运维管理
- 降低学习成本

代表产品：
- ArangoDB（文档+图+KV）
- OrientDB（文档+图）
- Cosmos DB（多模型）

注意事项：
- 功能深度可能不如专用数据库
- 性能优化空间有限
- 锁定风险

AI驱动的数据库

应用场景：
1. 智能调优：自动优化SQL和索引
2. 异常检测：AI发现性能异常
3. 容量预测：预测资源需求
4. 自动扩缩容：基于负载自动调整

代表产品：
- Oracle Autonomous Database
- 阿里云DAS（数据库自治服务）
- AWS DevOps Guru

发展趋势：
- 减少人工运维
- 提高系统稳定性
- 降低运维成本

总结与建议

选型黄金法则

没有银弹：不存在最好的数据库，只有最适合的数据库
业务驱动：技术选型服务于业务需求
数据说话：用POC验证代替主观判断
团队优先：考虑团队技术栈和学习成本
演进思维：架构随业务发展而演进

最后的话

数据库选型是一个复杂的决策过程，需要综合考虑技术、业务、团队、成本等多个维度。希望本文的案例分析和实践经验能够帮助你做出更明智的决策。

记住：好的架构是演进出来的，不是设计出来的。从简单开始，根据实际需求逐步优化，才是数据库选型的正确姿势。

附录：数据库选型检查清单

功能性检查清单

□ 是否支持所需的数据类型？
  □ 基本类型：整数、浮点、字符串、日期
  □ 高级类型：JSON、数组、地理坐标
  □ 二进制数据：BLOB、文件存储

□ 事务支持是否满足需求？
  □ ACID完整性
  □ 隔离级别配置
  □ 分布式事务支持

□ 查询能力评估
  □ 复杂JOIN支持
  □ 子查询性能
  □ 窗口函数
  □ 全文搜索
  □ 正则表达式

□ 扩展功能需求
  □ 存储过程/函数
  □ 触发器
  □ 视图
  □ 物化视图

非功能性检查清单

□ 性能指标
  □ 单条查询延迟
  □ 并发处理能力
  □ 写入吞吐量
  □ 批量操作性能

□ 可用性要求
  □ 主从复制
  □ 自动故障转移
  □ 数据备份恢复
  □ 灾难恢复能力

□ 扩展性评估
  □ 垂直扩展限制
  □ 水平扩展方案
  □ 分片策略
  □ 数据迁移工具

□ 安全性要求
  □ 数据加密
  □ 访问控制
  □ 审计日志
  □ 合规认证

运维检查清单

□ 监控能力
  □ 性能指标监控
  □ 慢查询分析
  □ 错误日志
  □ 告警机制

□ 运维工具
  □ 图形化管理工具
  □ 命令行工具
  □ 备份恢复工具
  □ 性能分析工具

□ 社区支持
  □ 官方文档质量
  □ 社区活跃度
  □ 第三方工具生态
  □ 商业支持选项

数据库选型决策记录模板

# 数据库选型决策记录

## 项目信息
- 项目名称：
- 决策日期：
- 决策人：
- 评审人：

## 业务背景
- 业务类型：
- 数据规模：
- 并发要求：
- 一致性要求：

## 候选方案

### 方案1：MySQL
- 优点：
- 缺点：
- 风险评估：

### 方案2：PostgreSQL
- 优点：
- 缺点：
- 风险评估：

### 方案3：其他
- 优点：
- 缺点：
- 风险评估：

## POC测试结果

| 测试项 | MySQL | PostgreSQL | 其他 | 备注 |
|--------|-------|-----------|------|------|
| 写入性能 | | | | |
| 查询性能 | | | | |
| 并发性能 | | | | |
| 功能满足度 | | | | |

## 成本分析

| 成本项 | MySQL | PostgreSQL | 其他 |
|--------|-------|-----------|------|
| 授权费用 | | | |
| 硬件成本 | | | |
| 人力成本 | | | |
| 运维成本 | | | |
| 3年TCO | | | |

## 决策结论
- 最终选择：
- 选择理由：
- 风险缓解措施：
- 回退方案：

## 后续行动
- [ ] 团队培训
- [ ] 环境搭建
- [ ] POC验证
- [ ] 上线计划

参考资料与延伸阅读

官方文档

MySQL官方文档：https://dev.mysql.com/doc/
PostgreSQL官方文档：https://www.postgresql.org/docs/
MongoDB官方文档：https://docs.mongodb.com/
Redis官方文档：https://redis.io/documentation

在线资源

DB-Engines排名：https://db-engines.com/en/ranking
数据库选型指南：https://www.digitalocean.com/community/tutorials/understanding-database-sharding
云数据库对比：https://www.g2.com/categories/cloud-database

社区与论坛

MySQL中文社区：http://www.mysqlchina.com/
PostgreSQL中文社区：http://www.postgres.cn/
MongoDB中文社区：https://mongoing.com/

文档版本：v1.0
最后更新：2024年1月
作者：技术团队
审核：架构委员会

数据库选型决策：MySQL、PostgreSQL、NoSQL的实战选择

问题引入：一个真实的选型困境

现象描述：选型失误的代价

案例1：盲目追求新技术

案例2：忽视数据一致性

原因分析：数据库特性深度剖析

关系型 vs 非关系型数据库

MySQL vs PostgreSQL 深度对比

1. 功能特性

2. 性能对比（基于sysbench测试）

NoSQL数据库选型矩阵

解决方案：电商系统数据库选型实战

我们的混合架构设计

选型决策矩阵

实施步骤：选型评估流程

第一步：需求分析清单

第二步：POC验证

第三步：成本评估

效果验证：优化前后的对比

商品详情页性能

订单系统稳定性

经验总结：数据库选型最佳实践

✅ 应该做的

❌ 不应该做的

扩展思考：云原生时代的数据库选型

Serverless数据库趋势

多模数据库的兴起

读者练习

进一步学习

深度案例分析：金融系统数据库选型

项目背景

选型过程

阶段一：需求梳理

阶段二：技术选型对比

阶段三：最终架构

关键技术决策

决策1：为什么核心交易选择MySQL而非Oracle？

决策2：为什么引入ClickHouse？

实施过程中的挑战

挑战1：数据一致性保障

挑战2：热点账户处理

效果评估

性能指标

业务价值

数据库选型决策树

常见选型误区与避坑指南

误区1：盲目追求高性能

误区2：忽视团队能力

误区3：过度设计

误区4：忽视数据迁移成本

数据库选型评估模板

技术评估维度

成本评估模板

未来趋势展望

云原生数据库

多模数据库

AI驱动的数据库

总结与建议

选型黄金法则

推荐选型路径

最后的话

附录：数据库选型检查清单

功能性检查清单

非功能性检查清单

运维检查清单

数据库选型决策记录模板

参考资料与延伸阅读

官方文档

推荐书籍

在线资源

社区与论坛

知识点测试

评论区