数据库如何确保其操作被 % 正确执行？.docxVIP

数据库如何确保其操作被 100% 正确执行？ ACID 是原子性（Atomicity，或称“不行分割性”）、全都性（Consistency）、隔离性（Isolation，又称“独立性”）、长久性（Durability）的首字母简称。Andreas Reuter 和 TheoH?rder 这两位前辈在 1983 年提出它，指出一个数据库“事务”只需满足这 4 个特性，在任何情况下数据都能保证精确?????。 “事务”是数据库的执行单元，除了我们平常用显式声明的 transaction 之类关键字包裹的代码外，每一条单独的 SQL，也是以事务的方式执行的。比如，当你在一条 SQL 中同时 insert 多笔数据的时候，一旦发生特别，全部的这几笔数据最终都不会被插入到目标表中，会一并撤销。 在保证达到这个效果的过程中，ACID 的四个特性分别起到了什么作用呢？ 1. 原子性 一句话来概括原子性，用于保证每个事务被视为单个完整的个体，不行分割。满足原子性的事务，要么完全成功，要么完全失败，不允许存在其他两头形态。通常这点指的是我们同时执行多条 SQL 语句的时候，可以将这些 SQL 语句的生效与否捆绑到一起，以保证最终要么全部数据被更新到数据库，要么全部都不更新到数据库。我们来看一个例子。 小明让小王代购了一些东西回来，需要在微信上领取给他 1000 元。当小明输入完金额点击“确认转账”之后，执行的 SQL 至少是这样的： update balance = balance - 1000 from account where id = 小明的 id`` update balance = balance + 1000 from account where id = 小王的 id 留意，这两条语句中只需任意一条执行失败，而另外一条执行成功，那么从原子性的要求来说，全部执行成功的修改都需要一并撤销，恢复到最后的形态，这个撤销操作我们称为“回滚”。否则，微信体系中的总余额会无故多出或少了 1000 元。 数据库中原子性的主流实现方案是通过日志来做的，每一次操作数据前都会先将当前数据记录到日志中，这样在需要回滚时，我们只需把 Undo Log 中的数据拿出来还原，就可以撤销已经执行成功的操作。 原子性是四个特性中最核心的一个，仅关注当前的这一次操作，不考虑能否存在其它的什么操作。 2. 隔离性 在上面小明和小王的故事中，假如再消灭一个人小张，他也让小王代购了东西要付钱，会消灭新的情况，如下图。 留意一下红字部分。我们发觉，这个时候哪怕两次转账的事务分别保证了原子性，并且执行成功，最终的结果还是有可能出错。 上图中的现象，我们称为“丢失更新”（Lost Update）。当然，还有其他可能产生的现象，比如脏读、不行反复读、幻读，等等。不过，我们临时不需要过多纠结于这些现象，你只需记得：当仅满足原子性的前提下，假如遇到并发执行，照旧会消灭数据错误。 所以，这时候我们需要通过隔离性的指点来避开这些问题。隔离性本质上指点处理的是一个资源竞争问题，通俗点说，就是多个事务并发执行后的形态，应当和它们串行执行后的形态是全都的。 在数据库中处理资源竞争问题与其它软件系统无异，就用锁。在数据库中对锁的运用不同，因而产生了不同的隔离级别，不同的隔离级别对应处理的是前面提到的这些特别现象。如，读未提交（Read Uncommitted）处理了丢失更新，读已提交（Read committed）多处理了脏读，可反复读（Repeatable Read）又多处理了不行反复读问题，最高级别的可序列化（Serializable）处理了全部这 4 个问题，即丢失更新、脏读、不行反复度、幻读。 其实在实际的运用中，遇到的场景会更简单，所以詹姆士·格雷（Jim Gray）等人在 1995 发表了论文“对 ANSI SQL 隔离级别的批判（A Critique of ANSI SQL Isolation Levels）”将上表做了扩充，添加了游标稳定（Cursor Stability）和快照隔离（Snapshot Isolation）隔离级别，指点我们在做隔离时，可以为获得更好的功能进行一些新的尝试。 3. 长久性 当你使用一些云产品写文章的时候，洋洋洒洒写了几千字，安心睡觉去了，其次天起来发觉内容停留在刚起笔的那几个字。任何的数据变更完成之后，就相当于成为了“历史”，需要保存下来才能为将来所用。因而数据库需要具备长久性，才能为我们所依靠用于存储数据。 如今，我们几乎都是利用硬盘作为数据库的存储介质，来保证长久性。那么理论上，除非硬盘本身毛病，否则都不应当消灭这样一种情况：一条 SQL 变更成功后，发生数据丢失或者数据回到更早的形态。 另外，由于所依靠的存储介质本身也可能消灭毛病，所以我们