[!info] related notes

• 所属 MOC: 数据库 MOC
• 相关概念: 关系型数据库, 事务
• 易混淆概念:
• 相关资源: MySQL, PostgreSQL, SQLite

MySQL、PostgreSQL 与 SQLite 的使用差异

范围

这篇不比较所有语法细节，而是回答一个更工程化的问题：

• 当你真要选数据库时，这三者分别更像什么角色
• 它们在部署模型、并发、事务与工程成本上为什么不同

为什么要放在一起理解

初学数据库时，最容易出现两个误区：

• 把所有关系型数据库看成只是语法不同
• 把 SQLite 当成“缩水版主库”，或把 MySQL / PostgreSQL 当成“只是更重的 SQLite”

实际上，这三者最大的差异首先不在函数名，而在它们所处的架构位置：

• SQLite 是嵌入式数据库
• MySQL 和 PostgreSQL 是独立数据库服务

先把这个位置差异看清，后面的并发、事务、运维和选型差异才会自然很多。

为什么这些差异会同时出现

数据库一旦部署位置不同，很多能力就会跟着改变：

• 谁负责启动和运维
• 谁来管理连接和权限
• 并发客户端是单机内少量调用，还是网络上的大量请求
• 事务冲突主要来自本地访问，还是来自服务端多连接竞争

所以三者的使用差异，本质上不是“数据库 A 比数据库 B 强”，而是：

• 它们优先优化的工程问题不同

依赖路径 / 调用链 / 演进链

SQLite

• 嵌入式
• 单文件为主
• 适合本地持久化、离线副本、桌面应用和轻量实验

MySQL

• 服务端数据库
• Web 业务系统非常常见
• 适合典型 CRUD 和 OLTP 场景

PostgreSQL

• 服务端数据库
• 更强调标准、扩展性、复杂查询和强数据语义
• 常见于需要高级类型、强约束和长期演进空间的系统

对比与易混淆点

维度	SQLite	MySQL	PostgreSQL
架构位置	嵌入应用、应用内数据库	独立数据库服务	独立数据库服务
主要优化目标	本地持久化、部署简单	通用业务主库、成熟生态	强表达力主库、复杂查询与约束
并发写能力	较弱，不适合高并发中心写库	较强	较强
事务语义关注点	单机、本地、文件级持久化体验	Web 业务事务、InnoDB 并发与日志	MVCC、WAL、复杂查询与一致性语义
运维成本	最低	中等	中等到偏高
典型场景	本地数据库、原型、离线、桌面应用	通用业务系统	通用业务系统、复杂查询与扩展

如果从选型问题出发，可以怎么想

1. 先问：它是不是应用内存储

如果核心需求是：

• 本地持久化
• 单机工具
• 离线优先客户端
• 不想引入独立服务进程

那优先考虑 SQLite 往往最自然。

2. 再问：它是不是通用业务主库

如果核心需求是：

• 独立数据库服务
• 后端业务系统
• 常规事务和 CRUD 为主
• 团队要低心智负担和成熟生态

那 MySQL 往往是非常稳的默认候选。

3. 最后问：是不是需要更强表达力和长期复杂性承载

如果核心需求是：

• 更强的类型系统和约束能力
• 更复杂的查询表达
• 更愿意把数据语义放在数据库层

那 PostgreSQL 往往更有吸引力。

一个很常见的误区

很多人会把三者理解成：

• SQLite < MySQL < PostgreSQL

这种“高低配”链条并不稳妥。

更准确的理解通常是：

• SQLite 和后二者首先是角色不同
• MySQL 和 PostgreSQL 才更像“两个不同风格的服务端主库”

学习顺序上怎么安排更稳

如果目标是系统学习数据库，常见更稳的顺序是：

1. 先理解 关系型数据库 和 SQL
2. 再理解 事务、索引、查询执行
3. 然后把 MySQL 和 PostgreSQL 作为服务端主库对照学习
4. 最后把 SQLite 放回“嵌入式数据库”这个正确位置理解

如果反过来把 SQLite 当成通用主库模板，再去看 MySQL / PostgreSQL，常常会建立出错误直觉。

边界与易混淆点

• SQLite 不是“弱一点的 MySQL / PostgreSQL”，而是部署位置和目标场景不同。
• MySQL 和 PostgreSQL 都能做通用业务主库，差异更多体现在表达力、默认语义、实现细节和团队偏好。
• 选型不是只看性能数字，还要看部署复杂度、事务模型、并发模式、团队经验和长期演进路径。