什么是数据库
数据库是一个长期存储在计算机内、有组织、可共享的数据集合，由数据库管理系统（DBMS） 统一管理。
DBMS（数据库管理系统）
DBMS 是数据库的核心软件，它屏蔽了底层存储和并发细节，对外提供统一的数据操作接口。DBMS 的核心职责包括：
- 数据定义：创建、修改表结构（DDL）
- 数据操作：增删改查（DML）
- 数据控制：权限、事务、并发、恢复
- 数据持久化：将数据可靠地写入磁盘
CRUD（基本数据操作）
| 操作 | 英文 | SQL 示例 | 说明 |
|---|---|---|---|
| 创建 | Create | INSERT INTO ... | 新增一条或多条记录 |
| 读取 | Read / Retrieve | SELECT ... | 查询记录，可带条件、排序、聚合 |
| 更新 | Update | UPDATE ... SET ... | 修改已有记录 |
| 删除 | Delete | DELETE FROM ... | 删除记录 |
CRUD 是所有数据库应用的基础，理解它们才能进一步讨论索引、事务、性能优化。
ACID（事务的四个特性）
事务是一组 CRUD 操作的逻辑单元，要么全部成功，要么全部失败。ACID 保证了事务的可靠性：
| 特性 | 含义 | 工程意义 |
|---|---|---|
| 原子性（Atomicity） | 事务中的所有操作作为一个整体，要么全部提交，要么全部回滚 | 防止部分操作成功导致数据不一致（例如转账扣款后未加款） |
| 一致性（Consistency） | 事务执行前后，数据库从一种合法状态变为另一种合法状态（约束、触发器、级联等不被破坏） | 保证业务规则始终成立（例如金额不为负、外键有效） |
| 隔离性（Isolation） | 多个事务并发执行时，互不干扰，如同串行执行 | 避免脏读、不可重复读、幻读等问题，通过锁或多版本并发控制（MVCC）实现 |
| 持久性（Durability） | 事务一旦提交，其修改永久保存，即使系统崩溃也不丢失 | 依靠日志（WAL）和定期刷盘机制保证 |
title:Important
不是所有数据库都完全支持 ACID。例如 Redis 默认不保证持久性（可配置），MongoDB 早期只支持文档级原子性。选型时必须明确业务对 ACID 的需求。发展现状
当前数据库领域呈现以下三大核心趋势：
-
关系型依然是绝对主流
MySQL 和 PostgreSQL 占据绝大多数 OLTP 场景。原因：SQL 标准、ACID、生态成熟、运维简单。
NewSQL（如 TiDB）试图解决关系型水平扩展难题，但复杂度较高，非必须不引入。 -
NoSQL 只用于特定场景
Redis（缓存/高速读写）、MongoDB（灵活 schema）、Elasticsearch（搜索）、时序库（监控数据）各司其职。
误区：不要用 NoSQL 替代关系型做通用存储，除非真的遇到关系型无法解决的水平扩展或 schema 频繁变更问题。 -
多模与云原生成为新常态
- 一个项目同时使用 MySQL + Redis + ES 非常普遍。
- 云数据库（RDS、Aurora、PolarDB）大幅降低运维成本，存储计算分离成为主流。
- PostgreSQL 通过插件支持 JSON、向量、键值等多种模型，减少技术栈数量。
title:Summary
中小项目用单机 MySQL/PostgreSQL + Redis 足够；遇到瓶颈再专项扩展，不要过早引入复杂技术。主流框架
这里“框架”不是指 ORM，而是指多个数据库产品协同工作的典型组合，用于解决不同层次的需求。
核心组合：关系型 + 缓存
| 组合 | 适用场景 | 说明 |
|---|---|---|
| MySQL / PostgreSQL + Redis | 绝大多数 Web 应用、业务系统 | 关系型作为持久化主存储，Redis 做缓存（热数据）、会话、计数器、分布式锁。这是最成熟、成本最低的方案。 |
| MySQL / PostgreSQL 单机 | 数据量小、并发低的内部系统 | 连 Redis 都不需要，直接一个数据库完成所有工作。 |
扩展组合
| 加入的数据库 | 解决的问题 | 典型场景 |
|---|---|---|
| Elasticsearch | 全文搜索、日志分析、模糊查询 | 电商商品搜索、应用日志平台（ELK） |
| MongoDB | schema 频繁变化、嵌套文档 | 内容管理、用户画像、配置中心 |
| ClickHouse / InfluxDB | 海量时序数据、高吞吐写入 | 监控指标、IoT 传感器数据 |
| Neo4j | 深度关系查询、图遍历 | 社交网络、推荐、反欺诈 |
| TiDB / CockroachDB | 关系型数据库的水平扩展 | 数据量超过单机 MySQL 上限（>1TB）且必须用 SQL + 事务 |
小团队/快速原型方案
只用 PostgreSQL（甚至不用 Redis）。
原因：PostgreSQL 支持 JSONB、全文检索、部分内存表，可以模拟文档型 + 缓存的部分功能。等业务增长到需要分离时再拆分。
工程铁律：永远先从一个关系型数据库开始，只有在真实瓶颈出现时才引入第二种数据库。每多一种数据库，运维复杂度增加一倍。
分类
以下是对数据库的理论分类，具体产品的深入细节将记录在专门的学习笔记中，这里只提炼最核心的区分维度。
按数据模型分类
| 模型 | 核心特征 | 典型产品 |
|---|---|---|
| 关系型 | 二维表 + SQL + ACID | MYSQL, PostgreSQL, SQLite |
| 键值型 | 哈希表结构，通过 Key 访问 Value | Redis, Memcached, RocksDB |
| 文档型 | 半结构化数据（JSON/BSON），无固定 schema | MongoDB, Couchbase |
| 列族型 | 按列存储，适合宽表、高写入 | Cassandra, HBase |
| 图型 | 节点 + 关系，擅长路径查询 | Neo4j, ArangoDB |
| 时序型 | 以时间戳为主键，高压缩比 | InfluxDB, Prometheus, TimescaleDB |
| 搜索引擎 | 倒排索引，全文检索 | Elasticsearch, Solr |
按系统架构分类
| 架构 | 特点 | 代表 |
|---|---|---|
| 单机 | 简单，无网络开销 | SQLite, 单机 MySQL |
| 主从复制 | 读写分离，弱一致性或最终一致 | MySQL Replication, Redis Sentinel |
| 分片（Sharding） | 数据水平切分，可线性扩展 | MongoDB Sharding, Redis Cluster |
| 分布式事务 | 跨节点 ACID，复杂度高 | TiDB, Spanner, CockroachDB |
| 存储计算分离 | 云原生，弹性伸缩 | Aurora, PolarDB, Snowflake |
按一致性/可用性权衡（CAP 理论）
- CP 系统：优先保证一致性和分区容错性，牺牲部分可用性（如 Zookeeper、HBase）
- AP 系统：优先保证可用性和分区容错性，最终一致性（如 Cassandra、CouchDB）
- CA 系统：不处理网络分区（实际上分布式系统中无法完全满足，常见于单机数据库）
工程提醒：CAP 是理论边界，实际产品可调节（如 Cassandra 可配置读写一致性级别）。理解 CAP 有助于判断为什么某些数据库不支持强事务。