copy from https://zhuanlan.zhihu.com/p/123281298
会话，即session，当你使用工具如sqlplus或者toad执行连接，连接到某个数据库的时候，就开启了一个会话，直到你关闭这次连接，这个会话才算结束。一个会话可以启动多个事务

事务，即transaction，是一个由多条SQL语句组成的工作逻辑单元，这些语句要么全部执行成功，要么全部不执行。只有commit，rollback，或者关闭工具的情况下，事务才会结束。当一个事务结束之后，下一个可执行的SQL语句自动开启一个新的事务。事务具有4个属性：原子性，一致性，隔离性，持久性。这里不具体说。事务是指一个操作单元，要么成功，要么失败，没有中间状态。

事务有 4 类隔离级别：

隔离级别	脏读	不可重复读	幻读
READ UNCOMMITTED	允许	可能	可能
READ COMMITTED	不允许	可能	可能
REPEATABLE READ	不允许	不允许	可能
SERIALIZABLE	不允许	不允许	不允许

串行化(Serializable，SQLite默认模式）：最高级别的隔离。两个同时发生的事务100%隔离，每个事务有自己的『世界』
可重复读（Repeatable read，MySQL默认模式）：每个事务有自己的『世界』，除了一种情况。如果一个事务成功执行并且添加了新数据，这些数据对其他正在执行的事务是可见的。但是如果事务成功修改了一条数据，修改结果对正在运行的事务不可见。所以，事务之间只是在新数据方面突破了隔离，对已存在的数据仍旧隔离。举个例子，如果事务A运行”SELECT count(1) from TABLE_X” ，然后事务B在 TABLE_X 加入一条新数据并提交，当事务A再运行一次 count(1)结果不会是一样的。这叫幻读（phantom read）。
读取已提交（Read committed，Oracle、PostgreSQL、SQL Server默认模式）：可重复读+新的隔离突破。如果事务A读取了数据D，然后数据D被事务B修改（或删除）并提交，事务A再次读取数据D时数据的变化（或删除）是可见的。这叫不可重复读（non-repeatable read）。
读取未提交（Read uncommitted）：最低级别的隔离，是读取已提交+新的隔离突破。如果事务A读取了数据D，然后数据D被事务B修改（但并未提交，事务B仍在运行中），事务A再次读取数据D时，数据修改是可见的。如果事务B回滚，那么事务A第二次读取的数据D是无意义的，因为那是事务B所做的从未发生的修改（已经回滚了嘛）。这叫脏读（dirty read）。

作者：陈广胜链接：https://www.zhihu.com/question/68724808/answer/299399908来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
读已提交（Read Committed）读已提交是PostgreSQL的默认隔离级别。SELECT只能看到已提交的事务所做出的更改，当前事务的更改除外。对于当前事务的更改，即便是未提交的，也是可见的。SELECT语句开始执行时，会获取一个快照(Snapshot)，保存事务的活动状态，通过这个快照判断事务的可见性。由于获取快照的时机是每个语句开始时，所以，即使是同一个事务的两个不同SELECT语句，也可能会返回不同的结果。即，可能会发生不可重复读或幻读的异常。
对于UPDATE，DELETE，SELECT FOR UPDATE， SELECT FOR SHARE语句，在查询时也会执行和SELECT语句类似的策略。这些语句只会看到当前语句开始时已提交的事务的更改。

如果事务要更新一条记录，而这条记录恰好被另一个运行中但未提交事务更改（被锁定或删除），则当前事务会阻塞，等待直到另一个事务提交或回滚后，再继续处理（First Updater Win Rule）。如果另一个事务回滚了，那么当前事务可以继续执行，更新这条记录。如果另一个事务提交了，要分两种情形。第一种，要是这条记录被删除了，那么忽略这条记录；第二种，这条记录被更新了，需要重新判断这条记录是否满足谓词条件(where语句)，满足则更新，不满足则忽略这条记录。

可重复读（Repeatable Read）可重复读隔离级别下，事务只能看到事务开始前已提交的数据。既不能看到未提交的数据，也不能看到事务在执行时被其它事务更新的已提交的数据。由于PostgreSQL使用的是多版本并发控制算法，实际上是snapshot隔离级别，比ANSI定义的隔离级别更高。
对于并发的更新操作，与读已提交是类似的。如果事务更新同一条记录，当前事务会阻塞直到另一个并发写的事务结束。如果另一个事务回滚，那么当前事务继续执行，更新这条记录。如果另一个事务提交了，当前事务会回滚，这里的处理与读已提交不同。

划重点： “脏读”和”不可重复读”这两个现象针对的是对于表中的同一个逻辑上的元组而言.引发”脏读”和”不可重复读”这两个现象的写事务的操作通常是UPDATE

幻读这一现象针对的已不是表中的单一元组而言，而是指读事务在对表中的某个范围多个元组而言的一种现象，引发幻读的写事务对应的操作通常是INSERT或DELETE。

不可重复读是另一个事务修改了数据，导致该事务多次读取出来的值不一样，而幻读是另一个事务插入或删除了记录，导致该事务多次读取出来的记录数不一样
不可重复读的解决只需要锁住会发生修改的记录就可以，幻读需要锁住更大的范围。
正是因为有这些问题存在，数据库设置了隔离级别来处理：

并发控制

锁

悲观锁/排他锁

共享锁

死锁—->两段锁

死锁

但是使用锁会导致一种情况，2个事务永远在等待一块数据：

原理 - 图1

在本图中：

事务A 给数据1 加上排他锁并且等待获取数据2
事务B 给数据2 加上排他锁并且等待获取数据1

这叫死锁。
在死锁发生时，锁管理器要选择取消（回滚）一个事务，以便消除死锁。这可是个艰难的决定：

杀死数据修改量最少的事务（这样能减少回滚的成本）？
杀死持续时间最短的事务，因为其它事务的用户等的时间更长？
杀死能用更少时间结束的事务（避免可能的资源饥荒）？
一旦发生回滚，有多少事务会受到回滚的影响？

在作出选择之前，锁管理器需要检查是否有死锁存在。
哈希表可以看作是个图表（见上文图），图中出现循环就说明有死锁。由于检查循环是昂贵的（所有锁组成的图表是很庞大的），经常会通过简单的途径解决：使用超时设定。如果一个锁在超时时间内没有加上，那事务就进入死锁状态。
锁管理器也可以在加锁之前检查该锁会不会变成死锁，但是想要完美的做到这一点还是很昂贵的。因此这些预检经常设置一些基本规则

两段锁

实现纯粹的隔离最简单的方法是：事务开始时获取锁，结束时释放锁。就是说，事务开始前必须等待确保自己能加上所有的锁，当事务结束时释放自己持有的锁。这是行得通的，但是为了等待所有的锁，大量的时间被浪费了。
更快的方法是两段锁协议（Two-Phase Locking Protocol，由 DB2 和 SQL Server使用），在这里，事务分为两个阶段：

成长阶段：事务可以获得锁，但不能释放锁。
收缩阶段：事务可以释放锁（对于已经处理完而且不会再次处理的数据），但不能获得新锁。

原理 - 图2

这两条简单规则背后的原理是：

释放不再使用的锁，来降低其它事务的等待时间
防止发生这类情况：事务最初获得的数据，在事务开始后被修改，当事务重新读取该数据时发生不一致。

这个规则可以很好地工作，但有个例外：如果修改了一条数据、释放了关联的锁后，事务被取消（回滚），而另一个事务读到了修改后的值，但最后这个值却被回滚。为了避免这个问题，所有独占锁必须在事务结束时释放。
多说几句
当然了，真实的数据库使用更复杂的系统，涉及到更多类型的锁（比如意向锁，intention locks）和更多的粒度（行级锁、页级锁、分区锁、表锁、表空间锁），但是道理是相同的。

版本控制

版本控制是这样的：

每个事务可以在相同时刻修改相同的数据
每个事务有自己的数据拷贝（或者叫版本）
如果2个事务修改相同的数据，只接受一个修改，另一个将被拒绝，相关的事务回滚（或重新运行）

这将提高性能，因为：

读事务不会阻塞写事务
写事务不会阻塞读
没有『臃肿缓慢』的锁管理器带来的额外开销

除了两个事务写相同数据的时候，数据版本控制各个方面都比锁表现得更好。只不过，你很快就会发现磁盘空间消耗巨大。
数据版本控制和锁机制是两种不同的见解：乐观锁和悲观锁。两者各有利弊，完全取决于使用场景（读多还是写多）。关于数据版本控制，我推荐这篇非常优秀的文章，讲的是PostgreSQL如何实现多版本并发控制的。
一些数据库，比如DB2（直到版本 9.7）和 SQL Server（不含快照隔离）仅使用锁机制。其他的像PostgreSQL, MySQL 和 Oracle 使用锁和鼠标版本控制混合机制。我不知道是否有仅用版本控制的数据库（如果你知道请告诉我）

日志管理器

我们已经知道，为了提升性能，数据库把数据保存在内存缓冲区内。但如果当事务提交时服务器崩溃，崩溃时还在内存里的数据会丢失，这破坏了事务的持久性。
你可以把所有数据都写在磁盘上，但是如果服务器崩溃，最终数据可能只有部分写入磁盘，这破坏了事务的原子性。
事务作出的任何修改必须是或者撤销，或者完成。
有 2 个办法解决这个问题：

影子副本/页（Shadow copies/pages）：每个事务创建自己的数据库副本（或部分数据库的副本），并基于这个副本来工作。一旦出错，这个副本就被移除；一旦成功，数据库立即使用文件系统的一个把戏，把副本替换到数据中，然后删掉『旧』数据。
事务日志（Transaction log）：事务日志是一个存储空间，在每次写盘之前，数据库在事务日志中写入一些信息，这样当事务崩溃或回滚，数据库知道如何移除或完成尚未完成的事务。

WAL（预写式日志）

ARIES
这个技术要达到一个双重目标：
1) 写日志的同时保持良好性能
2) 快速和可靠的数据恢复

有多个原因让数据库不得不回滚事务：

因为用户取消
因为服务器或网络故障
因为事务破坏了数据库完整性（比如一个列有唯一性约束而事务添加了重复值）
因为死锁

有时候（比如网络出现故障），数据库可以恢复事务。
这怎么可能呢？为了回答这个问题，我们需要了解日志里保存的信息

日志

事务的每一个操作（增/删/改）产生一条日志，由如下内容组成：

LSN：一个唯一的日志序列号（Log Sequence Number）。LSN是按时间顺序分配的 * ，这意味着如果操作 A 先于操作 B，log A 的 LSN 要比 log B 的 LSN 小。
TransID：产生操作的事务ID。
PageID：被修改的数据在磁盘上的位置。磁盘数据的最小单位是页，所以数据的位置就是它所处页的位置。
PrevLSN：同一个事务产生的上一条日志记录的链接。
UNDO：取消本次操作的方法。比如，如果操作是一次更新，UNDO将或者保存元素更新前的值/状态（物理UNDO），或者回到原来状态的反向操作（逻辑UNDO） **。
REDO：重复本次操作的方法。同样的，有 2 种方法：或者保存操作后的元素值/状态，或者保存操作本身以便重复。
…：（供您参考，一个 ARIES 日志还有 2 个字段：UndoNxtLSN 和 Type）。

进一步说，磁盘上每个页（保存数据的，不是保存日志的）都记录着最后一个修改该数据操作的LSN。
LSN的分配其实更复杂，因为它关系到日志存储的方式。但道理是相同的。
ARIES 只使用逻辑UNDO，因为处理物理UNDO太过混乱了。
注：据我所知，只有 PostgreSQL 没有使用UNDO，而是用一个垃圾回收服务来删除旧版本的数据。这个跟 PostgreSQL 对数据版本控制的实现有关。*
为了更好的说明这一点，这有一个简单的日志记录演示图，是由查询 “UPDATE FROM PERSON SET AGE = 18;” 产生的，我们假设这个查询是事务18执行的。

原理 - 图3

每条日志都有一个唯一的LSN，链接在一起的日志属于同一个事务。日志按照时间顺序链接（链接列表的最后一条日志是最后一个操作产生的）。

日志缓冲区

为了防止写日志成为主要的瓶颈，数据库使用了日志缓冲区。

原理 - 图4

当查询执行器要求做一次修改：

1) 缓存管理器将修改存入自己的缓冲区；
2) 日志管理器将相关的日志存入自己的缓冲区；
3) 到了这一步，查询执行器认为操作完成了（因此可以请求做另一次修改）；
4) 接着（不久以后）日志管理器把日志写入事务日志，什么时候写日志由某算法来决定。
5) 接着（不久以后）缓存管理器把修改写入磁盘，什么时候写盘由某算法来决定。

当事务提交，意味着事务每一个操作的 1 2 3 4 5 步骤都完成了。写事务日志是很快的，因为它只是『在事务日志某处增加一条日志』；而数据写盘就更复杂了，因为要用『能够快速读取的方式写入数据』。

STEAL 和 FORCE 策略

出于性能方面的原因，第 5 步有可能在提交之后完成，因为一旦发生崩溃，还有可能用REDO日志恢复事务。这叫做 NO-FORCE策略。
数据库可以选择FORCE策略（比如第 5 步在提交之前必须完成）来降低恢复时的负载。
另一个问题是，要选择数据是一步步的写入（STEAL策略），还是缓冲管理器需要等待提交命令来一次性全部写入（NO-STEAL策略）。选择STEAL还是NO-STEAL取决于你想要什么：快速写入但是从 UNDO 日志恢复缓慢，还是快速恢复。
总结一下这些策略对恢复的影响：

STEAL/NO-FORCE 需要 UNDO 和 REDO: 性能高，但是日志和恢复过程更复杂 (比如 ARIES)。多数数据库选择这个策略。注：这是我从多个学术论文和教程里看到的，但并没有看到官方文档里显式说明这一点。
STEAL/ FORCE 只需要 UNDO.
NO-STEAL/NO-FORCE 只需要 REDO.
NO-STEAL/FORCE 什么也不需要: 性能最差，而且需要巨大的内存。

关于恢复
Ok，有了不错的日志，我们来用用它们！
假设新来的实习生让数据库崩溃了（首要规矩：永远是实习生的错。），你重启了数据库，恢复过程开始了。
ARIES从崩溃中恢复有三个阶段：
1) 分析阶段：恢复进程读取全部事务日志，来重建崩溃过程中所发生事情的时间线，决定哪个事务要回滚（所有未提交的事务都要回滚）、崩溃时哪些数据需要写盘。
2) Redo阶段：这一关从分析中选中的一条日志记录开始，使用 REDO 来将数据库恢复到崩溃之前的状态。

在REDO阶段，REDO日志按照时间顺序处理（使用LSN）。
对每一条日志，恢复进程需要读取包含数据的磁盘页LSN。
如果LSN（磁盘页）>= LSN（日志记录），说明数据已经在崩溃前写到磁盘（但是值已经被日志之后、崩溃之前的某个操作覆盖），所以不需要做什么。
如果LSN（磁盘页）< LSN（日志记录），那么磁盘上的页将被更新。
即使将被回滚的事务，REDO也是要做的，因为这样简化了恢复过程（但是我相信现代数据库不会这么做的）。

3) Undo阶段：这一阶段回滚所有崩溃时未完成的事务。回滚从每个事务的最后一条日志开始，并且按照时间倒序处理UNDO日志（使用日志记录的PrevLSN）。

恢复过程中，事务日志必须留意恢复过程的操作，以便写入磁盘的数据与事务日志相一致。一个解决办法是移除被取消的事务产生的日志记录，但是这个太困难了。相反，ARIES在事务日志中记录补偿日志，来逻辑上删除被取消的事务的日志记录。
当事务被『手工』取消，或者被锁管理器取消（为了消除死锁），或仅仅因为网络故障而取消，那么分析阶段就不需要了。对于哪些需要 REDO 哪些需要 UNDO 的信息在 2 个内存表中：

事务表（保存当前所有事务的状态）
脏页表（保存哪些数据需要写入磁盘）

当新的事务产生时，这两个表由缓存管理器和事务管理器更新。因为是在内存中，当数据库崩溃时它们也被破坏掉了。
分析阶段的任务就是在崩溃之后，用事务日志中的信息重建上述的两个表。为了加快分析阶段，ARIES提出了一个概念：检查点（check point），就是不时地把事务表和脏页表的内容，还有此时最后一条LSN写入磁盘。那么在分析阶段当中，只需要分析这个LSN之后的日志即可。

原理