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

Motivation多个事务对于同一条数据进行修改 可能会出现竞争、更新丢失的问题 执行多条语句（事务）的时候机房发生断电，该如何处理 持久化（durability）的问题，需要恢复（recovery）解决 并发控制

三人三鬼过桥题目： 有三个人跟三个鬼要过河，河上没桥，只有条小船 船一次只能渡一个人和一个鬼，或者两个鬼，或者两个人 无论在哪边岸上，只要是人比鬼少的情况下（比如：两鬼一人，三鬼两人，三鬼一人），人都会被鬼吃 然而船又一定需要人或鬼操作才能

题干在一个 n x n 的矩阵 grid 中，除了在数组 mines 中给出的元素为 0，其他每个元素都为 1。mines[i] = [xi, yi]表示 grid[xi][yi] == 0 返回 grid 中包含 1 的最大的 轴对齐 加