数据库-数据库系统原理

数据库-数据库系统原理

 

　　　　落花人独立，微雨燕双飞。

 

简介：数据库-数据库系统原理。

1、事务

概念

事务指的是知足 ACID 特性的一组操做，能够经过 Commit 提交一个事务，也可使用 Rollback 进行回滚。

ACID

1. 原子性（Atomicity）

事务被视为不可分割的最小单元，事务的全部操做要么所有提交成功，要么所有失败回滚。

回滚能够用回滚日志（Undo Log）来实现，回滚日志记录着事务所执行的修改操做，在回滚时反向执行这些修改操做便可。

2. 一致性（Consistency）

数据库在事务执行先后都保持一致性状态。在一致性状态下，全部事务对同一个数据的读取结果都是相同的。

3. 隔离性（Isolation）

一个事务所作的修改在最终提交之前，对其它事务是不可见的。

4. 持久性（Durability）

一旦事务提交，则其所作的修改将会永远保存到数据库中。即便系统发生崩溃，事务执行的结果也不能丢失。

系统发生崩溃能够用重作日志（Redo Log）进行恢复，从而实现持久性。与回滚日志记录数据的逻辑修改不一样，重作日志记录的是数据页的物理修改。

事务的 ACID 特性概念简单，但不是很好理解，主要是由于这几个特性不是一种平级关系：

• 只有知足一致性，事务的执行结果才是正确的。
• 在无并发的状况下，事务串行执行，隔离性必定可以知足。此时只要能知足原子性，就必定能知足一致性。
• 在并发的状况下，多个事务并行执行，事务不只要知足原子性，还须要知足隔离性，才能知足一致性。
• 事务知足持久化是为了能应对系统崩溃的状况。

AUTOCOMMIT

MySQL 默认采用自动提交模式。也就是说，若是不显式使用 START TRANSACTION 语句来开始一个事务，那么每一个查询操做都会被当作一个事务并自动提交。

2、并发一致性问题

在并发环境下，事务的隔离性很难保证，所以会出现不少并发一致性问题。

丢失修改

丢失修改指一个事务的更新操做被另一个事务的更新操做替换。通常在现实生活中常会遇到，例如：T₁ 和 T₂ 两个事务都对一个数据进行修改，T₁ 先修改并提交生效，T₂ 随后修改，T₂ 的修改覆盖了 T₁ 的修改。

读脏数据

读脏数据指在不一样的事务下，当前事务能够读到另外事务未提交的数据。例如：T₁ 修改一个数据但未提交，T₂ 随后读取这个数据。若是 T₁ 撤销了此次修改，那么 T₂ 读取的数据是脏数据。

不可重复读

不可重复读指在一个事务内屡次读取同一数据集合。在这一事务还未结束前，另外一事务也访问了该同一数据集合并作了修改，因为第二个事务的修改，第一次事务的两次读取的数据可能不一致。例如：T₂ 读取一个数据，T₁ 对该数据作了修改。若是 T₂ 再次读取这个数据，此时读取的结果和第一次读取的结果不一样。

幻影读

幻读本质上也属于不可重复读的状况，T₁ 读取某个范围的数据，T₂ 在这个范围内插入新的数据，T₁ 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不一样。

产生并发不一致性问题的主要缘由是破坏了事务的隔离性，解决方法是经过并发控制来保证隔离性。并发控制能够经过封锁来实现，可是封锁操做须要用户本身控制，至关复杂。数据库管理系统提供了事务的隔离级别，让用户以一种更轻松的方式处理并发一致性问题。

3、封锁

封锁粒度

MySQL 中提供了两种封锁粒度：行级锁以及表级锁。

应该尽可能只锁定须要修改的那部分数据，而不是全部的资源。锁定的数据量越少，发生锁争用的可能就越小，系统的并发程度就越高。

可是加锁须要消耗资源，锁的各类操做（包括获取锁、释放锁、以及检查锁状态）都会增长系统开销。所以封锁粒度越小，系统开销就越大。

在选择封锁粒度时，须要在锁开销和并发程度之间作一个权衡。

封锁类型

1. 读写锁

• 互斥锁（Exclusive），简写为 X 锁，又称写锁。
• 共享锁（Shared），简写为 S 锁，又称读锁。

有如下两个规定：

• 一个事务对数据对象 A 加了 X 锁，就能够对 A 进行读取和更新。加锁期间其它事务不能对 A 加任何锁。
• 一个事务对数据对象 A 加了 S 锁，能够对 A 进行读取操做，可是不能进行更新操做。加锁期间其它事务能对 A 加 S 锁，可是不能加 X 锁。

2. 意向锁

使用意向锁（Intention Locks）能够更容易地支持多粒度封锁。

在存在行级锁和表级锁的状况下，事务 T 想要对表 A 加 X 锁，就须要先检测是否有其它事务对表 A 或者表 A 中的任意一行加了锁，那么就须要对表 A 的每一行都检测一次，这是很是耗时的。

意向锁在原来的 X/S 锁之上引入了 IX/IS，IX/IS 都是表锁，用来表示一个事务想要在表中的某个数据行上加 X 锁或 S 锁。有如下两个规定：

• 一个事务在得到某个数据行对象的 S 锁以前，必须先得到表的 IS 锁或者更强的锁；
• 一个事务在得到某个数据行对象的 X 锁以前，必须先得到表的 IX 锁。

经过引入意向锁，事务 T 想要对表 A 加 X 锁，只须要先检测是否有其它事务对表 A 加了 X/IX/S/IS 锁，若是加了就表示有其它事务正在使用这个表或者表中某一行的锁，所以事务 T 加 X 锁失败。

封锁协议

1. 三级封锁协议

一级封锁协议

事务 T 要修改数据 A 时必须加 X 锁，直到 T 结束才释放锁。

能够解决丢失修改问题，由于不能同时有两个事务对同一个数据进行修改，那么事务的修改就不会被覆盖。 

二级封锁协议

在一级的基础上，要求读取数据 A 时必须加 S 锁，读取完立刻释放 S 锁。

能够解决读脏数据问题，由于若是一个事务在对数据 A 进行修改，根据 1 级封锁协议，会加 X 锁，那么就不能再加 S 锁了，也就是不会读入数据。

三级封锁协议

在二级的基础上，要求读取数据 A 时必须加 S 锁，直到事务结束了才能释放 S 锁。

能够解决不可重复读的问题，由于读 A 时，其它事务不能对 A 加 X 锁，从而避免了在读的期间数据发生改变。

2. 两段锁协议

加锁和解锁分为两个阶段进行。

可串行化调度是指，经过并发控制，使得并发执行的事务结果与某个串行执行的事务结果相同。串行执行的事务互不干扰，不会出现并发一致性问题。

事务遵循两段锁协议是保证可串行化调度的充分条件。例如如下操做知足两段锁协议，它是可串行化调度。

lock-x(A)...lock-s(B)...lock-s(C)...unlock(A)...unlock(C)...unlock(B)

但不是必要条件，例如如下操做不知足两段锁协议，但它仍是可串行化调度。

lock-x(A)...unlock(A)...lock-s(B)...unlock(B)...lock-s(C)...unlock(C)

MySQL 隐式与显式锁定

MySQL 的 InnoDB 存储引擎采用两段锁协议，会根据隔离级别在须要的时候自动加锁，而且全部的锁都是在同一时刻被释放，这被称为隐式锁定。

InnoDB 也可使用特定的语句进行显示锁定：

1 SELECT ... LOCK In SHARE MODE; 2 SELECT ... FOR UPDATE;

4、隔离级别

未提交读（READ UNCOMMITTED）

事务中的修改，即便没有提交，对其它事务也是可见的。

提交读（READ COMMITTED）

一个事务只能读取已经提交的事务所作的修改。换句话说，一个事务所作的修改在提交以前对其它事务是不可见的。

可重复读（REPEATABLE READ）

保证在同一个事务中屡次读取同一数据的结果是同样的，可重复读为 Mysql 默认隔离级别。

可串行化（SERIALIZABLE）

强制事务串行执行，这样多个事务互不干扰，不会出现并发一致性问题。

该隔离级别须要加锁实现，由于要使用加锁机制保证同一时间只有一个事务执行，也就是保证事务串行执行。 

5、多版本并发控制

多版本并发控制（Multi-Version Concurrency Control, MVCC）是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种具体方式，用于实现提交读和可重复读这两种隔离级别。

提交读隔离级别老是读取最新的数据行，要求很低，无需使用 MVCC。

可串行化隔离级别须要对全部读取的行都加锁，单纯使用 MVCC 没法实现。

基本思想

在封锁一节中提到，加锁能解决多个事务同时执行时出现的并发一致性问题。在实际场景中读操做每每多于写操做，所以又引入了读写锁来避免没必要要的加锁操做，例如读和读没有互斥关系。读写锁中读和写操做仍然是互斥的，而 MVCC 利用了多版本的思想，写操做更新最新的版本快照，而读操做去读旧版本快照，没有互斥关系，这一点和 CopyOnWrite 相似。 

在 MVCC 中事务的修改操做（DELETE、INSERT、UPDATE）会为数据行新增一个版本快照。

脏读和不可重复读最根本的缘由是事务读取到其它事务未提交的修改。在事务进行读取操做时，为了解决脏读和不可重复读问题，MVCC 规定只能读取已经提交的快照。固然一个事务能够读取自身未提交的快照，这不算是脏读。 

版本号

• 系统版本号 SYS_ID：是一个递增的数字，每开始一个新的事务，系统版本号就会自动递增。
• 事务版本号 TRX_ID ：事务开始时的系统版本号。

Undo 日志

MVCC 的多版本指的是多个版本的快照，快照存储在 Undo 日志中，该日志经过回滚指针 ROLL_PTR 把一个数据行的全部快照链接起来。

例如在 MySQL 建立一个表 t，包含主键 id 和一个字段 x。咱们先插入一个数据行，而后对该数据行执行两次更新操做。

1 INSERT INTO t(id, x) VALUES(1, "a"); 2 UPDATE t SET x="b" WHERE id=1; 3 UPDATE t SET x="c" WHERE id=1;

由于没有使用 START TRANSACTION 将上面的操做当成一个事务来执行，根据 MySQL 的 AUTOCOMMIT 机制，每一个操做都会被当成一个事务来执行，因此上面的操做总共涉及到三个事务。快照中除了记录事务版本号 TRX_ID 和操做以外，还记录了一个 bit 的 DEL 字段，用于标记是否被删除。

INSERT、UPDATE、DELETE 操做会建立一个日志，并将事务版本号 TRX_ID 写入。DELETE 能够当作是一个特殊的 UPDATE，还会额外将 DEL 字段设置为 1。

ReadView

MVCC 维护了一个 ReadView 结构，主要包含了当前系统未提交的事务列表 TRX_IDs {TRX_ID_1, TRX_ID_2, ...}，还有该列表的最小值 TRX_ID_MIN 和 最大值 TRX_ID_MAX。

在进行 SELECT 操做时，根据数据行快照的 TRX_ID 与 TRX_ID_MIN 和 TRX_ID_MAX 之间的关系，从而判断数据行快照是否可使用：

• TRX_ID < TRX_ID_MIN，表示该数据行快照时在当前全部未提交事务以前进行更改的，所以可使用。

• TRX_ID > TRX_ID_MAX，表示该数据行快照是在事务启动以后被更改的，所以不可以使用。

• TRX_ID_MIN <= TRX_ID <= TRX_ID_MAX，须要根据隔离级别再进行判断：

  • 提交读：若是 TRX_ID 在 TRX_IDs 列表中，表示该数据行快照对应的事务还未提交，则该快照不可以使用。不然表示已经提交，可使用。
  • 可重复读：都不可使用。由于若是可使用的话，那么其它事务也能够读到这个数据行快照并进行修改，那么当前事务再去读这个数据行获得的值就会发生改变，也就是出现了不可重复读问题。

在数据行快照不可以使用的状况下，须要沿着 Undo Log 的回滚指针 ROLL_PTR 找到下一个快照，再进行上面的判断。

快照读与当前读

1. 快照读

MVCC 的 SELECT 操做是快照中的数据，不须要进行加锁操做。

SELECT * FROM table ...;

2. 当前读

MVCC 其它会对数据库进行修改的操做（INSERT、UPDATE、DELETE）须要进行加锁操做，从而读取最新的数据。能够看到 MVCC 并非彻底不用加锁，而只是避免了 SELECT 的加锁操做。

1 INSERT; 2 UPDATE; 3 DELETE;

在进行 SELECT 操做时，能够强制指定进行加锁操做。如下第一个语句须要加 S 锁，第二个须要加 X 锁。

1 SELECT * FROM table WHERE ? lock in share mode; 2 SELECT * FROM table WHERE ? for update;

6、Next-Key Locks

Next-Key Locks 是 MySQL 的 InnoDB 存储引擎的一种锁实现。

MVCC 不能解决幻影读问题，Next-Key Locks 就是为了解决这个问题而存在的。在可重复读（REPEATABLE READ）隔离级别下，使用 MVCC + Next-Key Locks 能够解决幻读问题。

Record Locks

锁定一个记录上的索引，而不是记录自己。

若是表没有设置索引，InnoDB 会自动在主键上建立隐藏的聚簇索引，所以 Record Locks 依然可使用。

Gap Locks

锁定索引之间的间隙，可是不包含索引自己。例如当一个事务执行如下语句，其它事务就不能在 t.c 中插入 15。

SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;

Next-Key Locks

它是 Record Locks 和 Gap Locks 的结合，不只锁定一个记录上的索引，也锁定索引之间的间隙。它锁定一个前开后闭区间，例如一个索引包含如下值：10, 11, 13, and 20，那么就须要锁定如下区间：

1 (-∞, 10] 2 (10, 11] 3 (11, 13] 4 (13, 20] 5 (20, +∞)

View Code

7、关系数据库设计理论

函数依赖

记 A->B 表示 A 函数决定 B，也能够说 B 函数依赖于 A。

若是 {A1，A2，... ，An} 是关系的一个或多个属性的集合，该集合函数决定了关系的其它全部属性而且是最小的，那么该集合就称为键码。

对于 A->B，若是能找到 A 的真子集 A'，使得 A'-> B，那么 A->B 就是部分函数依赖，不然就是彻底函数依赖。

对于 A->B，B->C，则 A->C 是一个传递函数依赖。

异常

如下的学生课程关系的函数依赖为 {Sno, Cname} -> {Sname, Sdept, Mname, Grade}，键码为 {Sno, Cname}。也就是说，肯定学生和课程以后，就能肯定其它信息。

Sno	Sname	Sdept	Mname	Cname	Grade
1	学生-1	学院-1	院长-1	课程-1	90
2	学生-2	学院-2	院长-2	课程-2	80
2	学生-2	学院-2	院长-2	课程-1	100
3	学生-3	学院-2	院长-2	课程-2	95

不符合范式的关系，会产生不少异常，主要有如下四种异常：

• 冗余数据：例如 学生-2 出现了两次。
• 修改异常：修改了一个记录中的信息，可是另外一个记录中相同的信息却没有被修改。
• 删除异常：删除一个信息，那么也会丢失其它信息。例如删除了 课程-1 须要删除第一行和第三行，那么 学生-1 的信息就会丢失。
• 插入异常：例如想要插入一个学生的信息，若是这个学生还没选课，那么就没法插入。

范式

范式理论是为了解决以上提到四种异常。

高级别范式的依赖于低级别的范式，1NF 是最低级别的范式。

1. 第一范式 (1NF)

属性不可分，即要求数据库表的每一列都是不可分割的原子数据项。

2. 第二范式 (2NF)

每一个非主属性彻底函数依赖于键码，即确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关。

能够经过分解来知足。

分解前

 

Sno	Sname	Sdept	Mname	Cname	Grade
1	学生-1	学院-1	院长-1	课程-1	90
2	学生-2	学院-2	院长-2	课程-2	80
2	学生-2	学院-2	院长-2	课程-1	100
3	学生-3	学院-2	院长-2	课程-2	95

以上学生课程关系中，{Sno, Cname} 为键码，有以下函数依赖：

• Sno -> Sname, Sdept
• Sdept -> Mname
• Sno, Cname-> Grade

Grade 彻底函数依赖于键码，它没有任何冗余数据，每一个学生的每门课都有特定的成绩。

Sname, Sdept 和 Mname 都部分依赖于键码，当一个学生选修了多门课时，这些数据就会出现屡次，形成大量冗余数据。

分解后

关系-1

Sno	Sname	Sdept	Mname
1	学生-1	学院-1	院长-1
2	学生-2	学院-2	院长-2
3	学生-3	学院-2	院长-2

有如下函数依赖：

• Sno -> Sname, Sdept
• Sdept -> Mname

关系-2

Sno	Cname	Grade
1	课程-1	90
2	课程-2	80
2	课程-1	100
3	课程-2	95

有如下函数依赖：

• Sno, Cname -> Grade 

3. 第三范式 (3NF)

非主属性不传递函数依赖于键码，即确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

上面的 关系-1 中存在如下传递函数依赖：

• Sno -> Sdept -> Mname

能够进行如下分解：

关系-11

Sno	Sname	Sdept
1	学生-1	学院-1
2	学生-2	学院-2
3	学生-3	学院-2

关系-12

Sdept	Mname
学院-1	院长-1
学院-2	院长-2

8、ER 图

Entity-Relationship，有三个组成部分：实体、属性、联系。

用来进行关系型数据库系统的概念设计。

 

 

 

 

落花人独立

微雨燕双飞