【数据库】技术栈全景——7 种数据库一句话定位与选型决策

关系型数据库（MySQL / PostgreSQL / SQLite）#

关系型数据库的核心，是**“表”**。

数据存在表里，每张表有固定的列（字段），每一行是一条记录。表和表之间通过外键关联。

1
用户表（users）
2
┌────┬──────────┬───────────────────┐
3
│ id │ name     │ email             │
4
├────┼──────────┼───────────────────┤
5
│  1 │ 昇哥     │ sheng@example.com │
6
│  2 │ 小明     │ ming@example.com  │
7
└────┴──────────┴───────────────────┘
8

9
订单表（orders）
10
┌────┬─────────┬──────────┬────────┐
11
│ id │ user_id │ product  │ amount │
12
├────┼─────────┼──────────┼────────┤
13
│  1 │       1 │ 汉服     │ 299.00 │
14
│  2 │       1 │ 茶叶     │  88.00 │
15
└────┴─────────┴──────────┴────────┘

orders.user_id 指向 users.id——这就是”关系”。

关系型数据库的三个核心优势：

1. 结构固定：Schema 先定好，数据按格式写进来，不会乱
2. 事务保证（ACID）：这个后面单独说，是关系型数据库最重要的特性
3. 查询能力强：SQL 可以做复杂的 JOIN、聚合、子查询

适合什么场景？

“数据不能出错”的场景——订单系统、财务系统、用户系统。

你不希望一笔钱扣了但订单没建上，也不希望用户表里突然多了一列莫名其妙的字段。关系型数据库的约束，正是为了防止这些事发生。

非关系型数据库（MongoDB / Redis / ES）#

非关系型数据库（NoSQL）不是一种数据库，是一类数据库的统称。

它们的共同点：不用表来组织数据，Schema 灵活，各有专长。

1
MongoDB（文档型）：数据是 JSON 文档
2
{
3
  "_id": "xxx",
4
  "user": "昇哥",
5
  "actions": ["点赞", "收藏", "分享"],
6
  "device": { "type": "mobile", "os": "iOS" }
7
}
8

9
Redis（键值型）：数据是 key-value
10
"session:abc123" → { userId: 1, role: "admin" }
11
"rank:weekly"    → [昇哥:9800, 小明:8800, ...]
12

13
Elasticsearch（搜索型）：数据是可检索的文档
14
全文搜索"汉服" → 返回相关度排序的结果列表

非关系型数据库的三个核心优势：

1. Schema 灵活：不需要提前定好表结构，字段可以随时增减
2. 水平扩展好：天然支持分布式，数据量大了可以横向加机器
3. 特定场景性能极高：Redis 的缓存、ES 的搜索，在各自场景下远超关系型

适合什么场景？

各有专长——Redis 做缓存，ES 做搜索，MongoDB 存灵活的 JSON 数据。不是”替代”关系型，是”补充”关系型。

一句话总结这个区别#

关系型：结构严格，数据可靠，查询灵活——适合”核心业务数据”。 非关系型：各有专长，灵活扩展——适合”特定场景的性能需求”。

A — Atomicity（原子性）#

一个事务里的所有操作，要么全部成功，要么全部失败。

最经典的例子：转账。

1
昇哥账户 -100 元
2
小明账户 +100 元

这两步必须同时成功，或者同时不发生。不能出现”昇哥扣了钱，但小明没收到”的情况。

原子性保证了这一点——如果第二步失败了，第一步会自动回滚。

C — Consistency（一致性）#

事务执行前后，数据库必须处于合法状态。

比如账户余额不能为负数，这是一个约束。一致性保证任何事务执行完之后，这个约束依然成立。

一致性是建立在原子性、隔离性、持久性之上的——其他三个保证了，一致性自然成立。

I — Isolation（隔离性）#

多个事务并发执行时，互相不干扰。

这是 ACID 里最复杂的一个，也是面试最爱考的。

想象两个用户同时抢最后一件商品：

1
事务 A：查询库存 → 库存=1 → 下单 → 库存-1
2
事务 B：查询库存 → 库存=1 → 下单 → 库存-1

如果没有隔离性，两个事务都看到库存=1，都下单成功，库存变成 -1——超卖了。

隔离性通过锁机制和隔离级别来保证，这个后面会单独写一篇深入讲。

D — Durability（持久性）#

事务一旦提交，数据就永久保存，不会因为宕机丢失。

数据库通过 WAL（Write-Ahead Log，预写日志）来保证这一点——先把操作写进日志，再写进数据文件。即使中途断电，重启后也能从日志恢复。

为什么 NoSQL 通常不保证完整的 ACID？#

因为 ACID 是有代价的——加锁、写日志、回滚，都会降低性能。

NoSQL 的设计取舍是：放弃部分一致性保证，换取更高的吞吐量和更好的扩展性。

Redis 有有限的事务支持（Lua 脚本），MongoDB 4.0 之后支持多文档事务，但都不如关系型数据库完整。这不是缺点，是设计选择——用在对的场景就好。

MySQL：最成熟的选择#

MySQL 是全球使用最广泛的开源关系型数据库。

适合： 中小型 Web 应用、团队已有 MySQL 经验、需要大量读操作的场景。

不适合： 复杂的分析查询、需要 JSONB 或地理空间数据、对 SQL 标准要求极高的场景。

一个真实的坑： MySQL 默认的隔离级别是 Repeatable Read，在某些场景下会有幻读问题。如果业务对数据一致性要求很高，需要显式设置隔离级别或者换 PostgreSQL。

PostgreSQL：更”正道”的选择#

PostgreSQL 是 SQL 标准兼容性最强的开源数据库，功能比 MySQL 丰富得多。

适合： 复杂查询（窗口函数、CTE、递归查询）、数据完整性要求极高、需要 JSONB / 地理空间 / 全文搜索等高级类型、AI 项目（pgvector 向量检索）。

不适合： 团队完全没有 PG 经验且项目简单、需要 AWS Aurora 等 MySQL 兼容的托管服务。

一个真实的感受： 学了 PG 的 SQL 标准写法，再看 MySQL 的差异，只是几个语法不同。反过来，习惯了 MySQL 的宽松模式，转到 PG 会有”为什么不让我这么写”的挫败感。这个坑，踩过才知道。

SQLite：被低估的数据库#

SQLite 不需要服务器，整个数据库就是一个文件。

适合： 移动端应用（iOS/Android 内置）、桌面工具、本地开发环境、不需要并发写入的小型应用。

不适合： 高并发写入、多进程同时访问、需要网络访问的服务端场景。

一个没想到的用法： 很多 AI 工具的本地存储用的就是 SQLite——轻量、零配置、够用。

MongoDB：Schema 灵活的代价#

MongoDB 存的是 JSON 文档，不需要提前定义表结构。

适合： 数据结构经常变化的早期项目、存储用户行为日志、内容管理系统（文章、评论结构复杂）。

不适合： 需要复杂关联查询、需要强事务保证的核心业务数据。

一个常见误区： “Schema 灵活”不是优点，是取舍。灵活意味着约束少，约束少意味着数据容易乱。用 MongoDB 存核心业务数据，后期维护会很痛苦。

Redis：不只是缓存#

很多人以为 Redis 就是”缓存数据库”。其实 Redis 是内存数据结构服务器，支持字符串、哈希、列表、集合、有序集合等多种数据结构。

适合：

• 缓存（热点数据、数据库查询结果）
• Session 存储
• 排行榜（有序集合天然支持）
• 实时计数（文章阅读数、点赞数）
• 分布式锁
• 消息队列（简单场景）

不适合： 存储需要持久化的核心业务数据（内存有限，重启有风险）。

一个关键认知： Redis 的高性能来自内存，但内存是有限的。用 Redis 做缓存，一定要设置过期时间（TTL），否则内存会被撑爆。

Elasticsearch：搜索引擎，不只是数据库#

ES 的核心是倒排索引——把文档里的每个词，映射到包含这个词的文档列表。

这让它能在海量文档里做毫秒级的全文搜索，这是 MySQL 的 LIKE 查询根本做不到的。

适合：

• 全文搜索（商品搜索、文章搜索）
• 日志分析（ELK Stack：Elasticsearch + Logstash + Kibana）
• RAG 知识库的语义检索（结合向量搜索）

不适合： 存储需要事务保证的业务数据、频繁更新的数据（ES 更新代价高）。

一个真实的用法： 在 AI / RAG 项目里，ES 可以做混合检索——关键词匹配 + 向量相似度，两路结合，比单纯向量检索效果更好。

IndexedDB：前端开发者的数据库#

IndexedDB 是浏览器内置的数据库，运行在客户端，数据存在用户本地。

适合： PWA（渐进式 Web 应用）、离线可用的 Web 应用、需要在浏览器端缓存大量数据的场景。

不适合： 服务端数据存储（它只在浏览器里）。

一个实际感受： IndexedDB 的 API 设计比较底层，直接用很繁琐。实际项目里通常用 Dexie.js 这类封装库。