外观
PostgreSQL、MySQL、MongoDB 数据库技术对比学习文档
适合人群:已经或正在学习 PostgreSQL、MySQL、MongoDB,想理解三者差异、选型依据、学习顺序和项目搭配的学习者。
核心提醒:PostgreSQL 和 MySQL 是 SQL 关系型数据库;MongoDB 是 NoSQL 文档数据库。三者都能存数据,但数据模型、查询方式、约束能力和最佳实践不同。
核对时间:2026-06-25。本文结合 PostgreSQL、MySQL、MongoDB 官方文档和前面三篇系统学习文档整理。
官方资料:
- PostgreSQL 文档:https://www.postgresql.org/docs/current/
- MySQL 文档:https://dev.mysql.com/doc/mysql/en/
- MongoDB 文档:https://www.mongodb.com/docs/
- Prisma ORM 文档:https://www.prisma.io/docs/orm
目录
- 一句话区别
- 核心对比总表
- 数据模型对比
- 查询语言对比
- 事务和一致性对比
- 索引能力对比
- JSON/文档能力对比
- 扩展和高可用对比
- 典型业务场景选择
- 和 Prisma ORM 的关系
- 学习顺序建议
- 面试和项目表达
- 选型口诀
1. 一句话区别
PostgreSQL:
text
功能强、SQL 能力强、类型和扩展丰富,适合复杂业务、复杂查询和重视数据一致性的系统。MySQL:
text
生态广、使用普及、运维经验丰富,适合大量常规 Web 业务、电商、后台系统和读写型业务。MongoDB:
text
文档模型灵活,适合半结构化数据、内容系统、事件日志、配置和以聚合文档为中心的业务。Prisma ORM:
text
不是数据库,而是 TypeScript/JavaScript 应用访问数据库的 ORM 工具,可连接 PostgreSQL、MySQL、MongoDB 等。2. 核心对比总表
| 维度 | PostgreSQL | MySQL | MongoDB |
|---|---|---|---|
| 类型 | SQL 关系型数据库 | SQL 关系型数据库 | NoSQL 文档数据库 |
| 核心模型 | 表、行、列 | 表、行、列 | 数据库、集合、文档 |
| 查询方式 | SQL | SQL | MongoDB Query API、Aggregation Pipeline |
| Schema | 强 schema | 强 schema | 灵活 schema,可加校验 |
| 关系建模 | 很强 | 很强 | 可引用,但不以 join 为核心 |
| 事务 | 强 | 强,InnoDB | 支持事务,但更推荐单文档原子设计 |
| JSON 能力 | JSON/JSONB 很强 | 支持 JSON | 原生文档模型 |
| 复杂查询 | 很强 | 强 | 聚合强,但复杂 join 不如关系型自然 |
| 索引 | B-tree、GIN、GiST、BRIN 等 | B-tree 为主,InnoDB 索引体系成熟 | 单字段、复合、文本、TTL、地理等 |
| 典型优势 | 复杂 SQL、扩展、数据一致性 | 普及、生态、读写业务 | 灵活文档、嵌套结构、快速迭代 |
| 常见场景 | SaaS、金融、GIS、复杂后台 | 电商、CMS、后台、业务系统 | 内容、日志、配置、事件、商品属性 |
| 学习重点 | SQL、事务、索引、执行计划、JSONB | SQL、InnoDB、索引、锁、字符集 | 文档建模、索引、聚合、嵌入/引用 |
3. 数据模型对比
3.1 PostgreSQL/MySQL:关系型模型
关系型数据库强调把数据拆成表,再通过主键和外键建立关系。
用户表:
sql
create table users (
id bigint primary key,
email varchar(255) not null unique,
name varchar(100) not null
);订单表:
sql
create table orders (
id bigint primary key,
user_id bigint not null,
status varchar(50) not null,
created_at timestamp not null
);订单项表:
sql
create table order_items (
id bigint primary key,
order_id bigint not null,
product_id bigint not null,
quantity int not null,
unit_price numeric(10, 2) not null
);优点:
- 数据结构清晰。
- 重复少。
- 约束强。
- 多表关联自然。
- 复杂查询能力强。
代价:
- 需要设计表关系。
- 查询时经常需要 join。
- schema 修改需要迁移。
3.2 MongoDB:文档模型
MongoDB 可以把一个订单作为一个文档:
json
{
"_id": "order1",
"userId": "user1",
"status": "paid",
"items": [
{
"productId": "p1",
"productName": "Keyboard",
"quantity": 1,
"unitPrice": 199.00
}
],
"createdAt": "2026-06-25T00:00:00Z"
}优点:
- 一个文档表达一个业务聚合。
- 读取完整对象方便。
- 字段结构灵活。
- 嵌套数组和对象自然。
代价:
- 关系约束不如关系型数据库自然。
- 数据冗余需要自己管理。
- 文档过大或数组无限增长会有问题。
- 复杂 join 不适合作为主路径。
3.3 建模思维差异
关系型数据库问:
text
有哪些实体?实体之间是什么关系?如何用表、主键、外键表达?MongoDB 问:
text
应用通常怎样读取数据?哪些数据应该作为一个聚合一起存取?如果你的业务天然是强关系,例如订单、支付、账户、权限、审批流,PostgreSQL/MySQL 更自然。
如果你的业务是文档、配置、事件、日志、商品扩展属性、内容块,MongoDB 会更舒服。
4. 查询语言对比
4.1 SQL 查询
PostgreSQL/MySQL:
sql
select users.name, count(orders.id) as order_count
from users
left join orders on orders.user_id = users.id
group by users.id, users.name
order by order_count desc
limit 20;SQL 优势:
- 声明式强。
- 复杂 join、聚合、窗口函数成熟。
- 数据分析和报表友好。
- 跨关系型数据库有通用基础。
4.2 MongoDB 查询
普通查询:
js
db.orders.find({
userId: "user1",
status: "paid"
}).sort({ createdAt: -1 }).limit(20);聚合管道:
js
db.orders.aggregate([
{ $match: { status: "paid" } },
{
$group: {
_id: "$userId",
orderCount: { $sum: 1 },
totalAmount: { $sum: "$amount" }
}
},
{ $sort: { totalAmount: -1 } },
{ $limit: 20 }
]);MongoDB 查询优势:
- 嵌套文档查询自然。
- 聚合管道适合文档转换和统计。
- 对 JSON 风格数据非常直观。
不适合:
- 大量复杂多集合 join。
- 强依赖 SQL 生态报表工具的系统。
5. 事务和一致性对比
5.1 PostgreSQL
PostgreSQL 事务能力强,默认隔离级别常用 Read Committed。它的 MVCC 设计成熟,复杂事务和一致性场景表现稳定。
适合:
- 金融账务
- 审批流
- 多表一致性
- 强约束业务
5.2 MySQL
MySQL 的事务主要依赖 InnoDB。InnoDB 支持 ACID、行锁、MVCC、崩溃恢复。常见默认隔离级别是 Repeatable Read。
学习重点:
- 聚簇索引
- 行锁和间隙锁
- 当前读和快照读
- 死锁排查
适合:
- 订单
- 库存
- 支付状态
- 常规业务系统
5.3 MongoDB
MongoDB 支持多文档事务,但最佳实践通常是通过文档模型让一个业务聚合尽量在单文档内完成原子更新。
单文档原子更新:
js
db.products.updateOne(
{ _id: productId, stock: { $gt: 0 } },
{ $inc: { stock: -1 } }
);如果业务大量依赖多文档事务,可能说明 MongoDB 不是最自然的选择,或者文档模型需要重新设计。
6. 索引能力对比
6.1 PostgreSQL 索引
常见:
- B-tree:默认通用索引。
- GIN:JSONB、数组、全文搜索常用。
- GiST:地理、范围等高级场景。
- BRIN:超大表、天然有序数据。
示例:
sql
create index idx_posts_author_created
on posts(author_id, created_at desc);PostgreSQL 的索引类型丰富,适合复杂查询和高级数据类型。
6.2 MySQL 索引
MySQL InnoDB 重点:
- 聚簇索引
- 二级索引
- 联合索引
- 最左前缀
- 回表
- 覆盖索引
示例:
sql
create index idx_orders_user_status_created
on orders(user_id, status, created_at);MySQL 索引学习必须结合 InnoDB 存储结构。
6.3 MongoDB 索引
常见:
- 单字段索引
- 复合索引
- 唯一索引
- TTL 索引
- 文本索引
- 地理空间索引
示例:
js
db.orders.createIndex({
userId: 1,
status: 1,
createdAt: -1
});MongoDB 索引同样要围绕真实查询模式设计。没有索引的大集合查询会非常慢。
7. JSON/文档能力对比
PostgreSQL:
- 支持 JSON 和 JSONB。
- JSONB 查询和索引能力强。
- 适合“关系型为主,部分字段半结构化”的业务。
MySQL:
- 支持 JSON 类型和 JSON 函数。
- 适合少量扩展字段。
- JSON 能力可用,但通常不作为主要建模方式。
MongoDB:
- 原生文档数据库。
- 嵌套对象和数组是一等模型。
- 适合以文档为核心的数据结构。
选择建议:
- 核心是关系,少量字段灵活:PostgreSQL/MySQL + JSON。
- 核心就是文档结构:MongoDB。
- 既要复杂关系又要大量 JSON 查询:优先评估 PostgreSQL JSONB。
8. 扩展和高可用对比
PostgreSQL:
- 主从复制
- 逻辑复制
- 分区表
- 丰富扩展
- 高可用通常依赖外部架构和运维方案
MySQL:
- 主从复制
- 读写分离
- 分库分表生态成熟
- InnoDB Cluster 等方案
- 大量云厂商和中间件支持
MongoDB:
- 副本集
- 分片集群
- 自动故障转移
- 原生水平扩展思路更突出
注意:扩展能力不是越早用越好。多数项目先把单机、索引、查询、连接池和备份做好,远比一开始就分片更重要。
9. 典型业务场景选择
9.1 用户、权限、订单、支付
推荐:
text
PostgreSQL 或 MySQL原因:
- 强关系。
- 强一致。
- 事务重要。
- 报表和审计常见。
9.2 内容管理、文章、评论
可选:
text
PostgreSQL / MySQL / MongoDB 都可以选择依据:
- 如果文章、用户、权限、审核强关系多:PostgreSQL/MySQL。
- 如果文章结构非常灵活,内容块差异很大:MongoDB。
9.3 商品属性和配置系统
推荐:
text
MongoDB 或 PostgreSQL JSONB原因:
- 字段变化频繁。
- 不同类型商品属性差异大。
- 配置文档结构灵活。
9.4 日志、事件、埋点
可选:
text
MongoDB / 专门日志系统 / PostgreSQL 分区表如果只是业务审计日志,PostgreSQL/MySQL 足够。如果是海量日志分析,可能需要 Elasticsearch、ClickHouse、Kafka 等专门系统。
9.5 SaaS 后台系统
推荐:
text
PostgreSQL 或 MySQL原因:
- 表关系清晰。
- 查询和报表多。
- 权限、租户、审计要求高。
PostgreSQL 在复杂查询、JSONB、多租户 schema、扩展方面更有优势;MySQL 在团队熟悉度、生态和常规业务中很稳。
10. 和 Prisma ORM 的关系
Prisma 不是第四种数据库技术。它是应用访问数据库的工具。
text
应用代码
↓
Prisma ORM
↓
PostgreSQL / MySQL / MongoDBPrisma 能做:
- 根据 schema 生成类型安全 Client。
- 管理迁移。
- 简化 CRUD。
- 提供关系查询 API。
Prisma 不能替你做:
- 数据库选型。
- 索引设计。
- 事务隔离理解。
- 生产迁移风险评估。
- 慢查询执行计划分析。
学习组合建议:
text
PostgreSQL/MySQL 基础
-> SQL、表设计、事务、索引
-> Prisma Schema
-> Prisma Client
-> Prisma Migrate
-> raw SQL 和性能优化MongoDB + Prisma 也可以使用,但要注意 MongoDB 的文档模型和关系型数据库不同,不应机械套用关系型 schema 思维。
11. 学习顺序建议
如果目标是全栈开发:
- 先学 SQL 基础。
- 在 PostgreSQL 和 MySQL 中任选一个深入。
- 学事务、索引、执行计划。
- 再学 Prisma ORM。
- 最后学习 MongoDB,理解文档建模。
如果目标是后端工程师:
- PostgreSQL 或 MySQL 深入。
- Redis 基础。
- MongoDB 文档模型。
- 数据库事务和锁。
- 慢查询优化和备份恢复。
- ORM 和迁移工具。
如果目标是前端全栈:
- Prisma + PostgreSQL 快速上手。
- 能设计基本表关系。
- 能用 Prisma 完成 CRUD。
- 学会看基础 SQL 和索引。
- 再扩展 MySQL 和 MongoDB。
推荐路线:
text
PostgreSQL 或 MySQL
-> Prisma ORM
-> MongoDB
-> PostgreSQL/MySQL 另一个数据库
-> 数据库性能优化12. 面试和项目表达
12.1 如何解释 PostgreSQL
可以这样说:
text
PostgreSQL 是功能很强的关系型数据库,适合复杂 SQL、事务一致性要求高、需要 JSONB 或扩展能力的系统。我会用它建模核心业务表,通过索引和 explain analyze 优化查询。关键词:
- SQL
- MVCC
- JSONB
- 索引类型
- explain analyze
- 事务隔离
12.2 如何解释 MySQL
可以这样说:
text
MySQL 是生态成熟的关系型数据库,常用于 Web 业务和后台系统。使用 InnoDB 时,需要重点理解聚簇索引、联合索引、最左前缀、事务隔离和锁。关键词:
- InnoDB
- 聚簇索引
- 二级索引
- 联合索引
- 最左前缀
- EXPLAIN
12.3 如何解释 MongoDB
可以这样说:
text
MongoDB 是文档型 NoSQL 数据库,适合字段灵活、文档结构明显、读写聚合对象的场景。建模时要在嵌入和引用之间选择,并用索引和聚合管道优化查询。关键词:
- Document
- Collection
- Embedded document
- Reference
- Aggregation pipeline
- Index
- Replica set
12.4 如何解释 Prisma
可以这样说:
text
Prisma 是 TypeScript 生态里的 ORM,负责根据 schema 生成类型安全 Client,并通过 Migrate 管理数据库结构变化。但它不能替代数据库知识,复杂查询和性能优化仍要回到 SQL、索引和执行计划。关键词:
- schema.prisma
- Prisma Client
- Prisma Migrate
- type-safe
- transaction
- raw SQL
13. 选型口诀
强关系、强事务、复杂查询:
text
优先 PostgreSQL 或 MySQL。复杂 SQL、JSONB、高级类型、扩展能力:
text
优先 PostgreSQL。常规 Web 业务、团队熟悉、生态成熟:
text
优先 MySQL。文档结构灵活、嵌套对象多、字段变化快:
text
考虑 MongoDB。TypeScript 项目想提高 CRUD 效率:
text
使用 Prisma,但仍然要学习底层数据库。不确定选什么:
text
默认先选 PostgreSQL 或 MySQL。只有当文档模型优势非常明确时,再选 MongoDB。最终建议
如果你正在构建前端全栈学习体系,推荐组合:
text
Tailwind CSS:负责 UI 样式
Monorepo:负责多项目工程组织
PostgreSQL/MySQL:负责核心关系型数据
Prisma ORM:负责 TypeScript 数据访问和迁移
MongoDB:负责文档型、半结构化或内容类场景扩展如果只选一个关系型数据库深入:
text
想学复杂能力和现代全栈:PostgreSQL。
想贴近大量传统业务和常见岗位:MySQL。如果最终都要掌握:
text
先学一个 SQL 数据库打基础,再对比另一个 SQL 数据库,最后学 MongoDB 的文档建模思维。