一前言
在巍峨的数据库大厦体系中，查询优化器和事务体系是两堵重要的承重墙，二者是如此重要以至于整个数据库体系结构设计中大量的数据结构、机制和特性都是围绕着二者搭建起来的。他们一个负责如何更快的查询到数据，更有效的组织起底层数据体系；一个负责安全、稳定、持久的存储数据，为用户的读写并发提供逻辑实现。我们今天探索的主题是事务体系，然而事务体系太过庞大，我们需要分成若干次的内容。本文就针对PolarDB事务体系中的原子性进行剖析。
二问题
在阅读本文之前，首先提出几个重要的问题，这几个问题或许在接触数据库之前你也曾经疑惑过。但是曾经这些问题的答案可能只是简单的被诸如“预写日志”，“崩溃恢复机制”等简单的答案回答过了，本文希望能够更深一步的讨论这些机制的实现及内在原理。
数据库原子性到底是如何保证的？使用了哪些特殊的数据结构？为什么要用？为什么我写入成功的数据能够被保证不丢失？为什么数据库崩溃后可以完整的恢复出来逻辑上我已经提交的数据？更进一步，什么是逻辑上已提交的数据？哪一个步骤才算是真正的提交？
三背景
1原子性在ACID中的位置
大名鼎鼎的ACID特性被提出后这个概念不断的被引用（最初被写入SQL92标准），这四种特性可以大概概括出人们心中对于数据库最核心的诉求。本文要讲的原子性便是其中第一个特性，我们先