From fa72a1fd784e0272271110692500e70d1f2b12ef Mon Sep 17 00:00:00 2001
From: CyC2018 <1029579233@qq.com>
Date: Sat, 14 Apr 2018 20:09:42 +0800
Subject: [PATCH] auto commit
---
notes/数据库系统原理.md | 36 +++++++++++++++++-------------------
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/notes/数据库系统原理.md b/notes/数据库系统原理.md
index d10a130a..19a76d1a 100644
--- a/notes/数据库系统原理.md
+++ b/notes/数据库系统原理.md
@@ -110,11 +110,13 @@ T1 读取某个范围的数据，T2 在这个范围内插
+MySQL 中提供了两种封锁粒度：行级锁以及表级锁。
+
应该尽量只锁定需要修改的那部分数据，而不是所有的资源。锁定的数据量越少，发生锁争用的可能就越小，系统的并发程度就越高。
-但是加锁需要消耗资源，锁的各种操作，包括获取锁，检查锁是否已经解除、释放锁，都会增加系统开销。因此封锁粒度越小，系统开销就越大。需要在锁开销以及数据安全性之间做一个权衡。
+但是加锁需要消耗资源，锁的各种操作，包括获取锁，检查锁是否已经解除、释放锁，都会增加系统开销。因此封锁粒度越小，系统开销就越大。
-MySQL 中提供了两种封锁粒度：行级锁以及表级锁。
+在选择封锁粒度时，需要在锁开销和并发程度之间做一个权衡。
## 封锁类型
@@ -289,33 +291,31 @@ InnoDB 的 MVCC 使用到的快照存储在 Undo 日志中，该日志通过回
### 1. SELECT
-该操作必须保证多个事务读取到同一个数据行的快照，这个快照是最近的一个有效快照。但是也有例外，如果有一个事务正在修改该数据行，那么它可以读取事务本身所做的修改，而不用和其它事务的读取结果一致。
-
当开始新一个事务时，该事务的版本号肯定会大于当前所有数据行快照的创建版本号，理解这一点很关键。
+多个事务必须读取到同一个数据行的快照，并且这个快照是距离现在最近的一个有效快照。但是也有例外，如果有一个事务正在修改该数据行，那么它可以读取事务本身所做的修改，而不用和其它事务的读取结果一致。
+
把没对一个数据行做修改的事务称为 T，T 所要读取的数据行快照的创建版本号必须小于 T 的版本号，因为如果大于或者等于 T 的版本号，那么表示该数据行快照是其它事务的最新修改，因此不能去读取它。
除了上面的要求，T 所要读取的数据行快照的删除版本号必须大于 T 的版本号，因为如果小于等于 T 的版本号，那么表示该数据行快照是已经被删除的，不应该去读取它。
### 2. INSERT
-将系统版本号作为数据行快照的创建版本号。
+将当前系统版本号作为数据行快照的创建版本号。
### 3. DELETE
-将系统版本号作为数据行快照的删除版本号。
+将当前系统版本号作为数据行快照的删除版本号。
### 4. UPDATE
-将系统版本号作为更新后的数据行快照的创建版本号，同时将系统版本号作为更新前的数据行快照的删除版本号。可以理解为先执行 DELETE 后执行 INSERT。
+将当前系统版本号作为更新后的数据行快照的创建版本号，同时将当前系统版本号作为更新前的数据行快照的删除版本号。可以理解为先执行 DELETE 后执行 INSERT。
## 快照读与当前读
### 1. 快照读
-读取快照中的数据。
-
-引入快照读的目的主要是为了免去加锁操作带来的性能开销，但是当前读需要加锁。
+读取快照中的数据，可以减少加锁所带来的开销。
```sql
select * from table ....;
@@ -323,9 +323,7 @@ select * from table ....;
### 2. 当前读
-读取最新的数据。
-
-需要加锁，以下第一个语句加 S 锁，其它都加 X 锁。
+读取最新的数据，需要加锁。以下第一个语句需要加 S 锁，其它都需要加 X 锁。
```sql
select * from table where ? lock in share mode;
@@ -337,7 +335,7 @@ delete;
# 六、Next-Key Locks
-Next-Key Locks 也是 MySQL 的 InnoDB 存储引擎的一种锁实现。MVCC 不能解决幻读的问题，Next-Key Locks 就是为了解决这个问题而存在的。在可重复读隔离级别下，MVCC + Next-Key Locks，就可以防止幻读的出现。
+Next-Key Locks 也是 MySQL 的 InnoDB 存储引擎的一种锁实现。MVCC 不能解决幻读的问题，Next-Key Locks 就是为了解决这个问题而存在的。在可重复读隔离级别下，使用 MVCC + Next-Key Locks 可以解决幻读问题。
## Record Locks
@@ -383,7 +381,7 @@ SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;
记 A->B 表示 A 函数决定 B，也可以说 B 函数依赖于 A。
-如果 {A1，A2，... ，An} 是关系的一个或多个属性的集合，该集合决定了关系的其它所有属性并且是最小的，那么该集合就称为键码。
+如果 {A1，A2，... ，An} 是关系的一个或多个属性的集合，该集合函数决定了关系的其它所有属性并且是最小的，那么该集合就称为键码。
对于 W->A，如果能找到 W 的真子集 W'，使得 W'-> A，那么 W->A 就是部分函数依赖，否则就是完全函数依赖；
@@ -399,9 +397,9 @@ SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;
不符合范式的关系，会产生很多异常，主要有以下四种异常：
-1. 冗余数据，例如学生-2 出现了两次。
-2. 修改异常，修改了一个记录中的信息，但是另一个记录中相同的信息却没有被修改。
-3. 删除异常，删除一个信息，那么也会丢失其它信息。例如如果删除了课程-1，需要删除第一行和第三行，那么学生-1 的信息就会丢失。
+1. 冗余数据：例如 学生-2 出现了两次。
+2. 修改异常：修改了一个记录中的信息，但是另一个记录中相同的信息却没有被修改。
+3. 删除异常：删除一个信息，那么也会丢失其它信息。例如如果删除了 课程-1，需要删除第一行和第三行，那么 学生-1 的信息就会丢失。
4. 插入异常，例如想要插入一个学生的信息，如果这个学生还没选课，那么就无法插入。
## 范式
@@ -470,7 +468,7 @@ Sname, Sdept 和 Mname 都函数依赖于 Sno，而部分依赖于键码。当
非主属性不传递依赖于键码。
-上面的关系-1 中存在以下传递依赖：Sno -> Sdept -> Mname，可以进行以下分解：
+上面的 关系-1 中存在以下传递依赖：Sno -> Sdept -> Mname，可以进行以下分解：
关系-11
