Why care about parallel execution上节课讨论的都是单个SQL语句是如何执行的，但是实际上我们很多时候都是多线程执行SQL语句 为什么要多线程并发执行 从单条语句看，能够提高响应时间（单独运行的情况下需要

Processing model执行模型有哪些，执行计划是如何运作的 DBMS的执行模型规定了系统是如何执行查询计划的 根据不同的工作负载（TP or AP），在执行计划上有不同的权衡 Approach 1 iterator mod

Why do we need to join因为数据在关系型数据库中的存储，是按照数据模型间的连接关系分开的 所以，如果想要获取一连串相关联的数据，就需要用join连表查询 本节主要研究的是内连接，用相等谓词连接的算法 在进行join的时候

Course status接下来的几节课里面，主要讲述以下内容： Operator Algorithms（具体的算子，比如join，sort是如何执行的） Query Processing Models（用什么方案执行查询，比如火山模型）

Decision support systems决策支持型数据库 分析当前的数据，以便对未来公司的发展做预计，帮助公司做商业决策 在这种AP型的数据库中，数据（表）的结构分为以下两种：star schema和snowflake schema

OLTP vs OLAPOn-line transaction processing（OLTP）事务的流程较短、语句较少、涉及数据的读写操作（可能写数据的情况会多一些） 一般来说，每个事务对整体数据的影响都很小 存在大量重复性的小事务

Parallel vs Distributed并行数据库和分布式数据库的区别 Parallel DBMS多个节点在物理上是放在一起的（比如说是放在同一个机房中） 物理节点之间是通过高速的局域网连接的 节点之间的通信消耗是很小的，可以忽略

Crash Recovery故障恢复算法是为了确保数据库一致性，事务的原子性和面对故障时数据的持久性的一种技术 故障恢复算法主要分为两部分： 第一部分：在正常的事务处理阶段添加一些操作，使得DBMS可以在故障发生时对数据进行恢复（防患于

Motivation从事务的角度来说，事务commit之后，使用者就会认为处理好的数据就被放到硬盘上了（并不管底层是如何实现的） 但实际上，出于对性能的考量（硬盘和磁盘的访问速度有明显差距） 实时修改的数据页是不会立刻写入到磁盘上的 而是优

Multi-version concurrency control多版本并发控制协议（常常和2PL或TOO一起实现并发控制） 对于DBMS中的每一个数据，都会去记录数据的所有版本（包括历史版本和当前版本） DBMS会维护当前所有数据对象的，

Background并发控制的两个流派：悲观的2PL，乐观的OCC 上一章讲到的2PL其实是一种悲观的并发控制协议 它假设未来所有的事务都会发生竞争，所以在操作每一条SQL的时候都会提前加上锁 即在问题发生之前解决问题，阻止问题的发生

Background上一章的分析都是基于事务已经发生了，然后再去判断分析是否可行 但实际上是不可能这么顺利的，因为我们不知道整个事务是怎么运行的 所以很自然的想到用锁实现多个事务的并发，从而实现对数据的保护 Lock types