系统
如下图所示，数据库管理系统作为中间节点，外接应用程序，内接物理硬件，其系统运作的主要目的是为了满足，因此需要有效的防范机制保证其内部运行。
（一）查询及优化
用户对数据库最频繁的操作为使用DML语言进行的各类操作，因此有必要对数据库的查询做出优化。
1.查询
查询分为四个流程：查询分析->查询检查->查询优化->查询执行。这四个流程是一条流水线。
场景：用户写了一条SQL语句对某关系表进行查询。SQL语句经过语言处理层时，进行查询分析，对SQL语法进行检查，接着进入数据存取层，进行查询检查，主要对SQL语句中的关系名、属性名是否存在和有效进行校验，同时进行完整性检查。检查无误后由查询优化器对SQL语句进行查询优化，最后执行优化后的代码并将结果返回。
2.优化
优化从两个维度着手，代数优化和物理优化。在我看来，代数优化由用户掌控，物理优化则通过优化存取路径及方法来实现。
2.1代数优化
代数关系与SQL语句对同一操作的描述有着对应关系，通过了解代数优化从而学习SQL优化。
做数学运算时我们常通过改变运算顺序更快捷求出结果。使用代数关系优化与数学运算的思想一致。
常用的代数关系优化规则有：
（1）选择运算尽可能先做；
（2）把投影运算和选择运算同时进行；
（3）把投影同其前或后的双目运算结合起来；
（4）把某些选择同在它前面要执行的笛卡尔积结合起来成为一个连接运算；
（5）找出公共子表达式；
选择、投影运算类似加减，计算方便；笛卡尔积相当于乘法，运算量大，公共子表达式类似合并同类项
2.2物理优化
数据均存在磁盘上，因此物理优化是对数据组织及联系进行优化。
2.2.1 对存取方法选择
存取方法的选择有两种：索引方法和聚簇方法。
2.2.1.1 索引方法
通常在关系中某一组属性或某个属性上建立索引（类似新华字典中大写字母ABC）。
2.2.1.1.1 B+树索引存取方法
以属性为单位，且以查询操作为主则考虑建立B+树索引，如果更新操作频繁则放弃。
（1）对某一个（组）属性的查询操作频繁；
（2）对某一个属性进行聚集函数类的操作；
（3）对某一个（组）属性在连接操作的连接条件中出现；
2.2.1.1.2 hash索引存取方法
（1）一个关系大小可预知，且不变；
（2）关系的大小动态改变，但数据库管理系统提供了动态hash存取方法。
2.2.1.2 聚簇方法
使用聚簇方法主要关注DML中对属性上的值操作是否频繁。
（1）对经常在一起进行连接操作的关系可以建立聚簇；
（2）一个关系的一组属性经常出现在相等比较条件中，这单个关系可以建立聚簇；
（3）一个关系的一个（组）属性上的值重复率很高，对这单个关系可以建立聚簇。
（二）恢复技术
恢复技术和并行控制的理论依据都基于事务。
1.事务
事务：用户定义的一个数据库操作序列，这些操作要么全做，要么全部做，是一个不可分割的工作单位（类似指令）
特点：原子性、一致性、隔离性和持续性。
原子性：事务中包括的诸操作要么都做，要么都不做（对应事务定义）；
一致性：事务执行的结果必须是使数据从一个一致性状态变到另一个一致性状态（数据的正确性特点）；
隔离性：一个事务的执行不能被其他事务干扰；
持续性：一个事务一旦提交，它对数据库中数据的改变就应该是持久性。
2.恢复技术
故障种类不同，采取的恢复策略也就不一样。
2.1分类
2.1.1事务内部故障（程序级）
事务内部故障可以分为可预期和非可预期。如运算溢出、并发事务发生死锁而被选中撤销该事务、违反了某些完整性限制而被终止。可预期故障由程序控制来避免，而非可预期故障则需要进行事务撤销。
各个事务的开始由 BEGIN TRANSACTION 标记，结束由 COMMIT 或 ROLLBACK 标记。若没有结束标记则表示事务发生非可预期故障。
2.1.2系统故障（软故障，系统级）
常指由于系统停止运转的任何事件，使得系统要重启。比如CPU错误、操作系统故障、DBMS代码错误和系统断电等。
2.1.3介质故障（硬故障，设备级）
通常指外存故障，如磁盘损坏等。
区别系统故障与介质故障主要从该故障由软、或是硬引起。
2.1.4计算机病毒（外界因素）
2.2技术实现
恢复技术通过冗余来实现，即数据（数据转储）和操作（日志文件）。
2.3策略
根据故障种类的分类恢复策略主要分为三种：事务故障恢复、系统故障恢复、介质故障恢复。除这三种策略外，还有检查点恢复技术。
2.3.1事务故障恢复
事务故障恢复的思路主要是反向扫描日志文件，通过扫描日志文件找出事务断点，并恢复到事务开始前的状态。
如下图，事务T1在t1时刻开始，t2时遇到故障，此时未完成所有操作，系统将反向扫描日志文件，将数据恢复到T1时刻前。
2.3.2系统故障恢复
正向扫描日志文件（找出已提交事务）+反向扫描文件（未提交事务）
对已提交事务进行 重做；
对未提交事务进行 撤销。
2.3.3介质故障恢复
重装数据库+重做已完成事务
2.3.4具有检查点的恢复技术
检查点技术用于解决搜索日志及重做事务花费时间大的问题，也就是省去从头开始的重复工作。数据转储记录的是数据，日志文件记录的是操作，检查点记录：
- 检查点时刻所有正在执行的事务 ；
-
这些事务的最近一个日志记录（日志文件）的地址
利用检查点记录，不需要从头扫描日志文件，只需要从检查点时刻开始扫描日志。
（三）并行控制
由于多个事务并行操作数据，会导致数据不一致性，为了保证事务的隔离性和一致性，对并行操作进行控制。
3.1出现数据不一致性的类型
3.1.1丢失修改（写-写错误）
两个事务同时对某一数据进行修改。
3.1.2不可重复读（读-写错误）
事务1读取数据，事务2对该数据进行修改，使事务1无法再读取前一次的结果。
3.1.3读“脏”数据（写-读错误）
事务1修改数据后写回，事务2读取该数据，事务1撤销操作，事务2读取的数据与之前不一致。
3.2解决办法—封锁
封锁策略是对操作数据的保护，但是对数据的操作程度不同，分为排他锁和写锁，这两种锁通常组合使用。
3.3封锁引起的问题—活锁和死锁
封锁的使用降低资源的流动性，引发活锁和死锁。
活锁造成某一事务长期等待，出现饥饿现象，解决办法采用先来先服务。
死锁则是多个事务之间长期等待，解决办法可以采用超时法和等待图法。
