Web 应用很少是完全独立运行的。用户请求经过 Web 服务器和应用程序后，通常还需要读取或修改数据库中的数据。

因此，理解数据库系统不能只停留在“会写 SQL”，还需要知道 DBMS、数据库、表、连接、事务、索引以及关系型与 NoSQL 数据库之间的关系。

本文从数据库系统的整体架构开始，介绍 DBMS、关系型数据库与 NoSQL、客户端与数据库连接、SQL、事务、ACID、并发控制、索引以及 Web 应用中的数据库访问流程，建立对数据库系统的整体认知。

数据库系统是什么#

数据库系统（Database System）可以理解为：

用于组织、存储、管理和访问数据的一整套系统。

一个完整的数据库系统通常不仅包括：

1
数据

还包括：

1
数据库管理系统
2
客户端 / 应用程序
3
数据库
4
用户

可以简单表示为：

1
用户
2
 │
3
 ▼
4
Web Application
5
 │
6
 ▼
7
DBMS
8
 │
9
 ▼
10
Database
11
 │
12
 ▼
13
数据

例如一个 Web 网站可能使用：

1
浏览器
2
   ↓
3
Nginx
4
   ↓
5
Java / Python 应用
6
   ↓
7
MySQL / PostgreSQL

数据库位于整个 Web 服务体系的后端。

DBMS#

什么是 DBMS#

DBMS（Database Management System，数据库管理系统）是：

负责创建、管理、访问和维护数据库的软件系统。

例如：

1
MySQL
2
PostgreSQL
3
MariaDB
4
Oracle Database
5
Microsoft SQL Server
6
MongoDB
7
Redis

都属于数据库系统中的具体产品，但它们的模型和能力并不完全相同。

可以把 DBMS 理解成：

1
Application
2
    │
3
    │ SQL / API
4
    ▼
5
   DBMS
6
    │
7
    ├── 连接管理
8
    ├── 查询解析
9
    ├── 查询执行
10
    ├── 事务管理
11
    ├── 并发控制
12
    ├── 权限控制
13
    ├── 缓存
14
    ├── 日志
15
    └── 存储管理
16
    │
17
    ▼
18
  Database

因此：

数据库是数据本身的组织与存储，而 DBMS 是管理这些数据的软件。

DBMS 与 Database 的区别#

这两个概念非常容易混淆。

可以简单理解成：

1
Database
2
↓
3
数据以及数据组织结构
4

5
DBMS
6
↓
7
管理 Database 的软件

例如：

1
MySQL
2
↓
3
DBMS
4

5
my_app
6
↓
7
MySQL 中的一个 Database

可以进一步理解成：

1
MySQL Server
2
│
3
├── Database A
4
│
5
├── Database B
6
└── Database C

不同 DBMS 对：

1
Database
2
Schema
3
Table
4
Namespace

等概念的组织方式可能有所不同，因此不能把一种数据库产品的层级结构机械套用到所有数据库上。

数据库系统的基本架构#

一个典型 Web 系统可以表示为：

1
                  Client
2
                     │
3
                     ▼
4
                Nginx / Apache
5
                     │
6
                     ▼
7
               Web Application
8
                     │
9
              Database Connection
10
                     │
11
                     ▼
12
                   DBMS
13
                     │
14
                     ▼
15
                 Database
16
                     │
17
                     ▼
18
                    Data

例如：

1
Browser
2
   │
3
   │ HTTP
4
   ▼
5
Nginx
6
   │
7
   │ Proxy
8
   ▼
9
Java Application
10
   │
11
   │ JDBC
12
   ▼
13
MySQL

其中：

1
HTTP
2
↓
3
Web 层通信
4

5
JDBC
6
↓
7
Java 应用访问数据库的接口
8

9
MySQL
10
↓
11
数据库管理系统

所以数据库并不是直接面对浏览器的。

数据模型#

数据库首先需要解决：

数据应该以什么方式组织？

不同数据库采用不同的数据模型。

常见的有：

1
关系模型
2
键值模型
3
文档模型
4
列族模型
5
图模型

在 Web 开发中，最常见的两大类可以先理解成：

1
关系型数据库
2
        +
3
NoSQL 数据库

关系型数据库#

什么是关系型数据库#

关系型数据库（Relational Database）以：

关系（Relation）

为核心组织数据。

实际使用中通常表现为：

1
Database
2
   │
3
   ├── Table
4
   │    ├── Row
5
   │    └── Column
6
   │
7
   └── Table

例如用户表：

id	name	age
1	Alice	20
2	Bob	21

可以理解成：

1
Table
2
 │
3
 ├── Column
4
 │   ├── id
5
 │   ├── name
6
 │   └── age
7
 │
8
 └── Row
9
     ├── 1
10
     ├── Alice
11
     └── 20

Table、Row 与 Column#

关系型数据库最基础的三个概念：

1
Table
2
Row
3
Column

可以简单理解：

1
Table
2
↓
3
一类数据
4

5
Row
6
↓
7
一条记录
8

9
Column
10
↓
11
某种属性

例如：

1
users

是一张用户表。

其中：

1
id
2
name
3
email

是列。

1
1
2
Alice
3
alice@example.com

是一行记录。

Primary Key#

关系型数据库中的一张表通常需要一种能够唯一标识记录的字段：

Primary Key（主键）

例如：

1
CREATE TABLE users (
2
    id BIGINT PRIMARY KEY,
3
    name VARCHAR(100)
4
);

这里：

1
id
2
↓
3
Primary Key

主键的核心作用是：

唯一标识表中的一条记录。

例如：

1
id = 1

只能对应一个用户。

Foreign Key#

不同表之间通常存在关系。

例如：

1
users
2
orders

一个用户可以拥有多个订单。

可以设计成：

1
users
2
┌────┐
3
│ id │
4
└─┬──┘
5
  │
6
  │ 1
7
  │
8
  │ N
9
  ▼
10
orders
11
┌─────────┐
12
│ user_id │
13
└─────────┘

这里：

1
orders.user_id

可以作为：

Foreign Key（外键）

引用：

1
users.id

从而表达：

1
用户
2
 ↓
3
订单

之间的关系。

SQL#

关系型数据库通常使用：

SQL（Structured Query Language）

进行数据定义、查询和修改。

常见操作：

1
SELECT
2
INSERT
3
UPDATE
4
DELETE
5
CREATE
6
ALTER
7
DROP

SELECT#

查询：

1
SELECT * FROM users;

表示：

1
查询 users 表中的记录

也可以只查询部分列：

1
SELECT id, name
2
FROM users;

INSERT#

插入：

1
INSERT INTO users (id, name)
2
VALUES (1, 'Alice');

UPDATE#

修改：

1
UPDATE users
2
SET name = 'Bob'
3
WHERE id = 1;

DELETE#

删除：

1
DELETE FROM users
2
WHERE id = 1;

需要特别注意：

不带正确条件的 UPDATE / DELETE 可能影响大量记录。

例如：

1
DELETE FROM users;

就是删除表中全部记录。

因此生产环境执行数据库修改操作时必须谨慎。

NoSQL#

什么是 NoSQL#

NoSQL 通常泛指：

不以传统关系模型为核心的数据存储系统。

NoSQL 并不是：

1
“完全不要 SQL”

而更接近：

1
Not Only SQL

现代 NoSQL 数据库包含很多不同的数据模型。

例如：

1
Key-Value
2
Document
3
Column Family
4
Graph

Key-Value#

键值数据库：

1
Key
2
 ↓
3
Value

例如：

1
user:1001
2
    ↓
3
Alice

典型数据库：

1
Redis

非常适合：

1
缓存
2
Session
3
计数器
4
分布式锁
5
排行榜

等场景。

Document Database#

文档数据库使用类似：

1
{
2
  "id": 1,
3
  "name": "Alice",
4
  "age": 20
5
}

这样的文档组织数据。

典型数据库：

1
MongoDB

它适合某些：

1
结构灵活
2
文档型数据
3
Schema 变化较快

的场景。

Column Family#

列族数据库常用于：

1
大规模分布式数据
2
高吞吐写入

典型系统包括：

1
Cassandra
2
HBase

其数据模型与传统关系型数据库不同。

Graph Database#

图数据库重点描述：

1
Node
2
+
3
Edge

例如：

1
Alice
2
 │
3
 │ 好友
4
 ▼
5
Bob
6
 │
7
 │ 好友
8
 ▼
9
Carol

典型场景：

1
社交关系
2
知识图谱
3
推荐关系
4
网络拓扑

关系型与 NoSQL 的区别#

可以从数据模型角度简单对比：

对比	关系型数据库	NoSQL
核心模型	表 / 关系	多种模型
Schema	通常较明确	通常更灵活
查询方式	SQL	各产品 API / 查询语言
事务	通常支持成熟 ACID	取决于具体产品
数据关系	擅长结构化关系	取决于模型
扩展方式	常见纵向扩展，也支持分布式方案	很多产品强调水平扩展
典型产品	MySQL / PostgreSQL	Redis / MongoDB / Cassandra

需要注意：

不能把“关系型 = 单机、NoSQL = 分布式”简单画等号。

现代关系型数据库同样可以运行在：

1
主从架构
2
集群
3
分片
4
云数据库

环境中。

而 NoSQL 数据库之间的设计差异也非常大。

因此数据库选型应该根据：

1
数据模型
2
事务要求
3
查询方式
4
一致性要求
5
性能
6
扩展需求
7
运维能力

综合判断。

数据库连接#

应用为什么需要连接数据库#

Web 应用要访问数据库，首先需要：

建立数据库连接。

例如：

1
Java Application
2
       │
3
       │ JDBC
4
       ▼
5
    Database

连接通常需要：

1
Host
2
Port
3
Database
4
Username
5
Password

例如：

1
Host = 127.0.0.1
2
Port = 3306
3
Database = app
4
User = app_user

Database Connection#

一个数据库连接可以简单理解成：

1
Application
2
     │
3
     │ Connect
4
     ▼
5
    DBMS
6
     │
7
     ▼
8
 Database

连接建立后：

1
Application
2
     │
3
     ├── SQL
4
     │
5
     ├── Result
6
     │
7
     └── Transaction
8
     │
9
     ▼
10
    DBMS

为什么需要连接池#

如果每个 HTTP 请求都：

1
创建数据库连接
2
 ↓
3
执行 SQL
4
 ↓
5
关闭连接

那么大量请求会产生：

1
连接建立开销
2
认证开销
3
Socket 开销
4
数据库资源消耗

例如：

1
1000 Requests
2
   │
3
   ├── 建立连接
4
   ├── 建立连接
5
   ├── 建立连接
6
   └── ...

因此 Web 应用通常使用：

Connection Pool（连接池）

Connection Pool#

连接池提前创建并维护一些数据库连接：

1
                Connection Pool
2
               ┌────┬────┬────┐
3
Application ──►│ C1 │ C2 │ C3 │
4
               ├────┼────┼────┤
5
               │ C4 │ C5 │ C6 │
6
               └────┴────┴────┘
7
                      │
8
                      ▼
9
                     DBMS

请求到来：

1
HTTP Request
2
     │
3
     ▼
4
Application
5
     │
6
     ▼
7
从连接池获取连接
8
     │
9
     ▼
10
执行 SQL
11
     │
12
     ▼
13
归还连接

而不是：

1
每次重新建立连接

连接池中的重要问题#

连接池并不是越大越好。

例如：

1
Connection Pool = 1000

并不意味着：

1
性能一定更好

因为数据库本身也存在：

1
CPU
2
内存
3
锁
4
连接数
5
磁盘 I/O

等资源限制。

如果连接池过大：

1
Application
2
   │
3
   ├── 100 connections
4
   ├── 100 connections
5
   └── ...
6
   ▼
7
Database
8
   │
9
   ▼
10
资源耗尽

反而可能导致数据库压力增加。

因此：

连接池大小需要结合应用并发量、SQL 耗时以及数据库能力进行配置。

事务#

什么是 Transaction#

事务（Transaction）可以理解为：

一组需要作为一个逻辑整体执行的数据库操作。

例如银行转账：

1
A -100
2
B +100

不能只执行一半。

应该：

1
开始事务
2
   │
3
   ▼
4
A -100
5
   │
6
   ▼
7
B +100
8
   │
9
   ▼
10
COMMIT

如果中间失败：

1
ROLLBACK

恢复之前的状态。

BEGIN、COMMIT 与 ROLLBACK#

事务可以简单理解为：

1
BEGIN
2
  │
3
  ▼
4
SQL 1
5
  │
6
  ▼
7
SQL 2
8
  │
9
  ▼
10
SQL 3
11
  │
12
  ├── 成功 → COMMIT
13
  │
14
  └── 失败 → ROLLBACK

例如：

1
START TRANSACTION;
2

3
UPDATE accounts
4
SET balance = balance - 100
5
WHERE id = 1;
6

7
UPDATE accounts
8
SET balance = balance + 100
9
WHERE id = 2;
10

11
COMMIT;

如果中间发现错误，可以：

1
ROLLBACK;

ACID#

数据库事务经常使用：

ACID

描述事务的重要特性。

1
A → Atomicity
2
C → Consistency
3
I → Isolation
4
D → Durability

Atomicity#

原子性：

一个事务中的操作要么全部成功，要么整体回滚。

例如：

1
A -100
2
B +100

不能只完成：

1
A -100

而：

1
B +100

失败后仍提交。

Consistency#

一致性：

事务执行前后，数据库应该满足定义好的完整性约束和业务规则。

例如：

1
账户余额
2
主键唯一
3
外键约束

等。

需要注意：

ACID 中的 Consistency 不只是“所有查询马上看到一样的数据”，而是事务需要把数据库从一个合法状态带到另一个合法状态。

Isolation#

隔离性：

并发执行的事务之间应该按照数据库定义的隔离规则互相影响。

例如：

1
Transaction A
2
      │
3
      ├── 修改数据
4
      │
5
Transaction B
6
      │
7
      └── 同时访问数据

数据库需要控制：

1
并发读写

带来的问题。

Durability#

持久性：

事务提交成功后，其结果应该具有持久保存的保证。

例如：

1
COMMIT
2
  ↓
3
数据库系统发生重启
4
  ↓
5
已提交的数据仍然应该被保留

具体保障机制涉及：

1
WAL
2
Redo Log
3
Flush
4
Storage

等底层机制。

并发事务#

现实中的数据库很少只有一个事务。

例如：

1
User A
2
   │
3
   ▼
4
Transaction A
5

6
User B
7
   │
8
   ▼
9
Transaction B

两个事务可能同时操作相同数据。

因此数据库需要：

Concurrency Control（并发控制）

常见并发问题#

Dirty Read#

事务 A 修改了数据：

1
A
2
↓
3
修改

事务 B 读取到这个尚未提交的数据。

如果 A 最后：

1
ROLLBACK

那么 B 读到的数据就不存在于最终状态中。

Non-Repeatable Read#

事务 A 两次读取同一条记录：

1
第一次
2
↓
3
100
4

5
第二次
6
↓
7
200

中间被其他事务修改并提交。

于是同一个事务中：

1
同一查询

前后得到不同结果。

Phantom Read#

第一次查询：

1
SELECT ...

得到：

1
10 行

之后另一个事务插入满足条件的新记录。

再次执行：

1
SELECT ...

得到：

1
11 行

新增的记录就像：

“突然出现的幻影”

因此称为：

Phantom Read

事务隔离级别#

SQL 标准定义了多个事务隔离级别，常见名称为：

1
READ UNCOMMITTED
2
READ COMMITTED
3
REPEATABLE READ
4
SERIALIZABLE

可以粗略理解成：

1
隔离性增强
2
      ↑
3
      │
4
READ UNCOMMITTED
5
      │
6
READ COMMITTED
7
      │
8
REPEATABLE READ
9
      │
10
SERIALIZABLE

一般来说：

隔离程度越高，并发事务之间的可见性限制越严格，但并发性能和锁 / 等待代价可能也越高。

不同数据库的具体实现并不完全一样。

例如：

1
MySQL
2
PostgreSQL
3
Oracle
4
SQL Server

对隔离级别的实现细节存在差异，因此实际使用时应该参考具体 DBMS 的文档。

索引#

什么是 Index#

数据库中的索引可以理解成：

为了加快数据查找而建立的额外数据结构。

如果一张表有：

1
10000000

条记录。

查询：

1
SELECT *
2
FROM users
3
WHERE email = 'alice@example.com';

如果没有合适索引，数据库可能需要：

1
逐行检查
2
 ↓
3
Row 1
4
Row 2
5
Row 3
6
...
7
Row 10000000

这种方式通常称为：

Full Table Scan（全表扫描）

有索引时#

假设：

1
email

有索引。

数据库可以：

1
查询条件
2
   ↓
3
Index
4
   ↓
5
定位记录
6
   ↓
7
读取数据

可以理解成：

1
Table
2
│
3
├── id
4
├── name
5
└── email
6

7
Index(email)
8
       │
9
       ▼
10
   目标记录

B+Tree 索引#

关系型数据库中非常常见的一类索引结构是：

B-Tree / B+Tree 家族

它适合：

1
等值查询
2
范围查询
3
排序

例如：

1
SELECT *
2
FROM users
3
WHERE id = 100;

或者：

1
SELECT *
2
FROM users
3
WHERE age BETWEEN 20 AND 30;

B+Tree 可以通过树结构减少需要访问的数据范围。

可以简化理解成：

1
             Root
2
           /      \
3
         Node     Node
4
        /  \      /  \
5
      ...  ...  ...  ...
6
             │
7
             ▼
8
          Target

实际数据库实现远比这个模型复杂，但理解：

1
索引
2
↓
3
缩小搜索范围

就足够建立第一层认识。

Hash Index#

另一类常见思路是：

Hash Index

可以通过：

1
Hash(Key)

快速定位。

例如：

1
email
2
 ↓
3
Hash
4
 ↓
5
Bucket

它适合某些：

1
等值查询

但不适合传统意义上的：

1
范围查询

因此：

1
WHERE id = 100

和：

1
WHERE id BETWEEN 100 AND 200

对索引结构的需求并不完全一样。

为什么不是索引越多越好#

索引能够加快查询，但也有成本。

例如：

1
INSERT
2
UPDATE
3
DELETE

发生时，相关索引也需要维护。

因此：

1
索引增加
2
↓
3
查询可能更快
4
↓
5
写入成本增加
6
↓
7
占用更多存储

所以：

索引设计本质上是在查询性能与写入 / 存储成本之间进行权衡。

组合索引#

数据库还经常使用：

Composite Index（联合索引）

例如：

1
CREATE INDEX idx_user
2
ON users (name, age);

表示索引包含：

1
name
2
age

两个字段。

联合索引涉及重要的：

最左前缀原则

例如索引：

1
(name, age)

通常更适合：

1
WHERE name = 'Alice';

以及：

1
WHERE name = 'Alice'
2
  AND age = 20;

而仅仅：

1
WHERE age = 20;

通常不能充分利用这个联合索引的前导部分。

具体行为仍取决于 DBMS 的优化器和索引实现。

索引与执行计划#

数据库并不会因为：

1
“存在索引”

就一定使用索引。

数据库通常会通过：

Query Optimizer（查询优化器）

分析查询。

例如：

1
SQL
2
 ↓
3
Parser
4
 ↓
5
Optimizer
6
 ↓
7
Execution Plan
8
 ↓
9
Executor

可能最终选择：

1
Index Scan

也可能选择：

1
Seq Scan

或者其他执行方式。

因此：

判断索引是否真正有效，需要观察执行计划，而不是只看数据库里有没有建立索引。

例如 PostgreSQL：

1
EXPLAIN
2
SELECT *
3
FROM users
4
WHERE email = 'alice@example.com';

MySQL 则可以：

1
EXPLAIN
2
SELECT *
3
FROM users
4
WHERE email = 'alice@example.com';

数据库查询执行#

一条 SQL 并不是直接：

1
SQL
2
 ↓
3
Disk

而是经过多个步骤。

可以简化为：

1
SQL
2
 │
3
 ▼
4
Parser
5
 │
6
 ▼
7
Query Analysis
8
 │
9
 ▼
10
Optimizer
11
 │
12
 ▼
13
Execution Plan
14
 │
15
 ▼
16
Executor
17
 │
18
 ▼
19
Storage Engine / Data
20
 │
21
 ▼
22
Result

例如：

1
SELECT *
2
FROM users
3
WHERE id = 100;

数据库可能：

1
解析 SQL
2
 ↓
3
识别 users 表
4
 ↓
5
识别 id 条件
6
 ↓
7
检查可用索引
8
 ↓
9
生成执行计划
10
 ↓
11
读取索引 / 数据
12
 ↓
13
返回结果

Buffer Cache#

数据库并不会每次都直接访问磁盘。

通常会在内存中维护大量缓存：

1
Application
2
    │
3
    ▼
4
   DBMS
5
    │
6
    ▼
7
Buffer / Page Cache
8
    │
9
    ├── Hit → 直接使用
10
    │
11
    └── Miss
12
           │
13
           ▼
14
         Disk

因此数据库性能通常不仅取决于：

1
CPU

还取决于：

1
Memory
2
Disk
3
IOPS
4
Latency
5
Cache Hit

等因素。

这也是数据库性能分析比单纯查看 SQL 更复杂的原因之一。

数据持久化与日志#

数据库需要解决一个非常重要的问题：

系统突然崩溃时，已经提交的数据怎么办？

因此现代数据库通常会使用某种日志机制。

例如 PostgreSQL 中的重要机制：

1
WAL

即：

Write-Ahead Logging

核心思想可以简单理解为：

1
先记录恢复所需的日志
2
        ↓
3
再认为相关数据修改可以安全持久化

系统崩溃后，可以根据日志进行恢复。

因此：

1
Transaction
2
   ↓
3
Log
4
   ↓
5
Storage

是数据库持久化机制中的重要思想。

数据库备份#

需要注意：

事务持久性不等于备份。

即使数据库具有：

1
ACID
2
WAL
3
Crash Recovery

也不能解决：

1
误删
2
逻辑损坏
3
勒索
4
错误 UPDATE
5
错误 DROP

等问题。

因此生产环境仍然需要：

1
数据库备份
2
+
3
恢复测试

完整的数据库运维还需要进一步考虑：

1
全量备份
2
增量备份
3
日志备份
4
恢复
5
RPO
6
RTO

Web 应用访问数据库#

将前面的概念串起来，一个典型 Web 请求可能是：

1
Browser
2
   │
3
   │ HTTP
4
   ▼
5
Nginx
6
   │
7
   ▼
8
Web Application
9
   │
10
   │ Connection Pool
11
   ▼
12
DBMS
13
   │
14
   │ SQL
15
   ▼
16
Database

例如用户访问：

1
GET /users/100

应用可能执行：

1
SELECT *
2
FROM users
3
WHERE id = 100;

数据库处理：

1
SQL
2
 ↓
3
Parser
4
 ↓
5
Optimizer
6
 ↓
7
Index
8
 ↓
9
Data
10
 ↓
11
Result

然后：

1
Database
2
   │
3
   ▼
4
Web Application
5
   │
6
   ▼
7
HTTP Response
8
   │
9
   ▼
10
Browser

数据库连接与事务#

实际 Web 应用中，数据库访问通常还会包含：

1
HTTP Request
2
     │
3
     ▼
4
Application
5
     │
6
     ▼
7
Get Connection
8
     │
9
     ▼
10
Begin Transaction
11
     │
12
     ├── SQL 1
13
     ├── SQL 2
14
     └── SQL 3
15
     │
16
     ▼
17
Commit / Rollback
18
     │
19
     ▼
20
Return Connection
21
     │
22
     ▼
23
HTTP Response

因此：

1
HTTP
2
↓
3
Application
4
↓
5
Connection Pool
6
↓
7
Transaction
8
↓
9
SQL
10
↓
11
Index
12
↓
13
Database

实际上是一整条完整链路。

数据库常见性能问题#

数据库出现性能问题时，通常不能只看：

1
CPU

还应该考虑：

1
慢 SQL
2
索引缺失
3
索引失效
4
锁等待
5
事务过长
6
连接池耗尽
7
磁盘 I/O
8
缓存命中率
9
数据量增长

例如：

1
请求变慢
2
   │
3
   ▼
4
Application
5
   │
6
   ▼
7
等待数据库
8
   │
9
   ▼
10
慢 SQL
11
   │
12
   ▼
13
全表扫描
14
   │
15
   ▼
16
Disk I/O 增加

这种情况下：

1
Web Server

本身可能完全正常。

真正的瓶颈在：

1
Database

数据库故障排查思路#

可以形成一个基本流程：

1
Web 请求变慢
2
      │
3
      ▼
4
Application
5
      │
6
      ▼
7
数据库连接是否正常？
8
      │
9
      ▼
10
连接池是否耗尽？
11
      │
12
      ▼
13
SQL 是否执行？
14
      │
15
      ▼
16
SQL 是否很慢？
17
      │
18
      ▼
19
EXPLAIN / Execution Plan
20
      │
21
      ▼
22
是否使用合理索引？
23
      │
24
      ▼
25
是否存在锁等待？
26
      │
27
      ▼
28
数据库 CPU / Memory / I/O
29
      │
30
      ▼
31
进一步定位

这也是为什么数据库运维不能只停留在：

1
“会写 SELECT”

而需要同时理解：

1
连接
2
事务
3
锁
4
索引
5
执行计划
6
资源

关系型数据库与 Web 服务#

在传统 Web 系统中，一个非常典型的架构是：

1
                    Browser
2
                       │
3
                       ▼
4
                    Nginx
5
                       │
6
                       ▼
7
                Application
8
                       │
9
                ┌──────┴──────┐
10
                │             │
11
                ▼             ▼
12
          Connection Pool    Cache
13
                │
14
                ▼
15
              DBMS
16
                │
17
        ┌───────┴───────┐
18
        │               │
19
        ▼               ▼
20
      Table           Index
21
        │
22
        ▼
23
       Data

其中：

1
Nginx
2
↓
3
处理 HTTP / 代理
4

5
Application
6
↓
7
处理业务逻辑
8

9
Database
10
↓
11
持久化结构化数据
12

13
Cache
14
↓
15
减少部分数据库访问

这就是常见的：

Web + Application + Database

基本架构。

NoSQL 在 Web 系统中的位置#

NoSQL 数据库也经常出现在 Web 系统中。

例如：

1
Application
2
   │
3
   ├── MySQL
4
   │      ↓
5
   │   业务主数据
6
   │
7
   └── Redis
8
          ↓
9
        Cache

典型组合：

1
MySQL / PostgreSQL
2
↓
3
核心业务数据
4

5
Redis
6
↓
7
缓存 / Session / Counter
8

9
MongoDB
10
↓
11
文档型数据

因此：

关系型数据库和 NoSQL 并不是一定互相替代。

实际系统中经常是：

1
Polyglot Persistence

即根据不同数据和访问场景选择不同的数据存储系统。

数据库系统整体模型#

到这里，可以把数据库系统完整串起来：

1
                         Database System
2
                                │
3
             ┌──────────────────┼──────────────────┐
4
             │                  │                  │
5
             ▼                  ▼                  ▼
6
           DBMS              Data Model         Client
7
             │                  │                  │
8
       ┌─────┴─────┐       ┌────┼────┐             │
9
       │           │       │         │             │
10
  Relational     NoSQL   Table     Document      App
11
       │           │       │         │             │
12
       │       ┌───┼───┐   │         │             │
13
       │       │   │   │   │         │             │
14
       ▼       ▼   ▼   ▼   ▼         ▼             ▼
15
      SQL    KV  Doc Graph Row      Data         Connection
16
       │
17
       ▼
18
   Transaction
19
       │
20
       ├── Atomicity
21
       ├── Consistency
22
       ├── Isolation
23
       └── Durability
24
       │
25
       ▼
26
      Index
27
       │
28
       ▼
29
 Query Optimization
30
       │
31
       ▼
32
    Data Storage

可以进一步浓缩成：

1
Application
2
    ↓
3
Connection
4
    ↓
5
DBMS
6
    ↓
7
Query
8
    ↓
9
Transaction
10
    ↓
11
Optimizer
12
    ↓
13
Index
14
    ↓
15
Storage
16
    ↓
17
Data

从 Web 运维角度理解数据库#

对于 Web 运维来说，真正需要建立的并不是：

1
“数据库就是一个存数据的地方”

而是：

1
请求
2
 ↓
3
应用
4
 ↓
5
数据库连接
6
 ↓
7
事务
8
 ↓
9
SQL
10
 ↓
11
查询优化
12
 ↓
13
索引
14
 ↓
15
磁盘 / 内存

任何一环出现问题，都可能最终表现为：

1
页面变慢
2
API 超时
3
请求失败
4
数据库连接耗尽
5
CPU 飙高
6
I/O 飙高

例如：

1
API 响应变慢
2
       │
3
       ▼
4
应用等待 DB
5
       │
6
       ▼
7
数据库查询变慢
8
       │
9
       ▼
10
执行计划异常
11
       │
12
       ▼
13
没有使用合理索引
14
       │
15
       ▼
16
大量 I/O

因此数据库系统实际上是 Web 服务架构中非常核心的一层。

理解：

1
DBMS
2
关系型 / NoSQL
3
Connection
4
Transaction
5
Index
6
Query

之后，再学习：

1
MySQL
2
PostgreSQL
3
Redis
4
MongoDB
5
数据库备份
6
主从复制
7
高可用
8
数据库监控
9
慢查询

就会有比较清晰的基础。

数据库系统是什么#

DBMS#

什么是 DBMS#

DBMS 与 Database 的区别#

数据库系统的基本架构#

数据模型#

关系型数据库#

什么是关系型数据库#

Table、Row 与 Column#

Primary Key#

Foreign Key#

SQL#

SELECT#

INSERT#

UPDATE#

DELETE#

NoSQL#

什么是 NoSQL#

Key-Value#

Document Database#

Column Family#

Graph Database#

关系型与 NoSQL 的区别#

数据库连接#

应用为什么需要连接数据库#

Database Connection#

为什么需要连接池#

Connection Pool#

连接池中的重要问题#

事务#

什么是 Transaction#

BEGIN、COMMIT 与 ROLLBACK#

ACID#

Atomicity#

Consistency#

Isolation#

Durability#

并发事务#

常见并发问题#

Dirty Read#

Non-Repeatable Read#

Phantom Read#

事务隔离级别#

索引#

什么是 Index#

有索引时#

B+Tree 索引#

Hash Index#

为什么不是索引越多越好#

组合索引#

索引与执行计划#

数据库查询执行#

Buffer Cache#

数据持久化与日志#

数据库备份#

Web 应用访问数据库#

数据库连接与事务#

数据库常见性能问题#

数据库故障排查思路#

关系型数据库与 Web 服务#

NoSQL 在 Web 系统中的位置#

数据库系统整体模型#

从 Web 运维角度理解数据库#

外部参考#