read uncommit, read commit, repeatable read, 共享锁VS排他锁

一般大家都对事务的四种隔离模式比较熟悉，从松到严依次是：

- 读取未提交(Read uncommitted)：处于此模式下可能会出现脏读、幻象读、不可重复读

- 读取已提交(Read committed)：处于此模式下可能会出现幻象读、不可重复读

- 可重复读(Repeatable read)：处于此模式下可能会出现幻象读

- 串行(Serialize)：不会出现幻象读

 

那么脏读、幻象行、不可重复读是什么意思呢？

- 脏读：其它的事务（执行单个 select 语句也算一个事务）可以读取到某个事务更新（包括插入和删除）了但未提交的数据。脏读是应用中应该避免的，因为读取的是不可靠的数据（我觉得把这个叫做幻象行更形象，实际却不是）。一般数据库不会设定为这个模式，但有时候也会用到。脏读的好处是读取时不会对表或记录加锁，可以绕开写队列的排队，避免了等待。如在一个更新特别频繁的表中要选择表中所有的数据，就可以显示指定隔离级别：

select .... at isolation 0

 

- 不可重复读：这是描述在同一个事务中两条一模一样的 select 语句的执行结果的比较。如果前后执行的结果一样，则是可重复读；如果前后的结果可以不一样，则是不可重复读。这个特性从字面上也能看出来。

     不可重复读的模式下首先不会出现脏读，即读取的都是已提交的数据。在一个事务中，读取操作是不会加排他锁的，当下一条一模一样的 select 语句的执行时，命中的数据集可能已经被其它事务修改了，这时候，还能读到相同的内容吗？

     因此，要达到可重复读的效果，数据库需要做更多的事情，比如，对读取的数据行加共享锁，并保持到事务结束，以禁止其它事务修改它。这样会降低数据库的性能。而隔离级别的串行则比可重复读更严格。一般数据库的的隔离级别只设置到读取已提交。这是兼顾了可靠性和性能的结果。

     上面还只提到了对命中的数据行加锁，以防止其它事务修改它。但没有提到，如果其它事务增加了符合条件的数据行怎么办？有些数据库对这种情况新定义了两个级别：读取稳定性和游标稳定性。前者不限制新增符合条件的数据行，而后者则阻止新增这样的数据行。

 

- 幻象读：是指两次执行同一条 select 语句会出现不同的结果，第二次读会增加一数据行，并没有说这两次执行是在同一个事务中。一般情况下，幻象读应该正是我们所需要的。但有时候却不是，如果打开的游标，在对游标进行操作时，并不希望新增的记录加到游标命中的数据集中来。隔离级别为 游标稳定性 的，可以阻止幻象读。

-------------------------------------

数据库中事务的 ACID 原则

原子性 (Atomicity)： 事务的原子性是指一个事务中包含的一条语句或者多条语句构成了一个完整的逻辑单元，这个逻辑单元具有不可再分的原子性。这个逻辑单元要么一起提交执行全部成功，要么一起提交执行全部失败。

一致性 (Consistency)： 可以理解为数据的完整性，事务的提交要确保在数据库上的操作没有破坏数据的完整性，比如说不要违背一些约束的数据插入或者修改行为。一旦破坏了数据的完整性，SQL Server 会回滚这个事务来确保数据库中的数据是一致的。

隔离性(Isolation)： 与数据库中的事务隔离级别以及锁相关，多个用户可以对同一数据并发访问而又不破坏数据的正确性和完整性。但是，并行事务的修改必须与其它并行事务的修改相互独立，隔离。 但是在不同的隔离级别下，事务的读取操作可能得到的结果是不同的。

持久性(Durability)： 数据持久化，事务一旦对数据的操作完成并提交后，数据修改就已经完成，即使服务重启这些数据也不会改变。相反，如果在事务的执行过程中，系统服务崩溃或者重启，那么事务所有的操作就会被回滚，即回到事务操作之前的状态。

我理解在极端断电或者系统崩溃的情况下，一个发生在事务未提交之前，数据库应该记录了这个事务的"ID"和部分已经在数据库上更新的数据。供电恢复数据库重新启动之后，这时完成全部撤销和回滚操作。如果在事务提交之后的断电，有可能更改的结果没有正常写入磁盘持久化，但是有可能丢失的数据会通过事务日志自动恢复并重新生成以写入磁盘完成持久化。

----------------------------------

共享锁【S锁】

又称读锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。

排他锁【X锁】

又称写锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。这保证了其他事务在T释放A上的锁之前不能再读取和修改A。

----------------------------------

总结：隔离模式(isolation)其实就是对读写加锁的形象称谓，应用在每个具体事务上。对数据库本身而言，只有锁的概念并没有隔离模式的概念。当数据库发现某个对象被加上共享锁时，其他修改该对象的操作就被阻塞，直到该对象上的所有共享锁都被释放为止。