ACID特性
数据库管理系统中事务(transaction)的四个特性（分析时根据首字母缩写依次解释）：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）
所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。（执行单个逻辑功能的一组指令或操作称为事务）
详解
1. 原子性
原子性是指事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生。
可采用“A向B转账”这个例子来说明解释
在DBMS中，默认情况下一条SQL就是一个单独事务，事务是自动提交的。只有显式的使用start transaction开启一个事务，才能将一个代码块放在事务中执行。
2. 一致性
一致性是指在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。这是说数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。
如A给B转账，不论转账的事务操作是否成功，其两者的存款总额不变（这是业务逻辑的一致性，至于数据库关系约束的完整性就更好理解了）。
保障机制（也从两方面着手）：数据库层面会在一个事务执行之前和之后，数据会符合你设置的约束（唯一约束，外键约束,check约束等)和触发器设置；此外，数据库的内部数据结构（如 B 树索引或双向链表）都必须是正确的。业务的一致性一般由开发人员进行保证，亦可转移至数据库层面。
3. 隔离性
多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。
在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。
事务最复杂问题都是由事务隔离性引起的。完全的隔离性是不现实的，完全的隔离性要求数据库同一时间只执行一条事务，这样会严重影响性能。
关于隔离性中的事务隔离等级（事务之间影响），参见相应博文
4. 持久性
这是最好理解的一个特性：持久性，意味着在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。（完成的事务是系统永久的部分，对系统的影响是永久性的，该修改即使出现致命的系统故障也将一直保持）
write ahead logging：SQL Server中使用了WAL（Write-Ahead Logging）技术来保证事务日志的ACID特性，在数据写入到数据库之前，先写入到日志，再将日志记录变更到存储器中。
三类数据读问题
1.Dirty Read（脏读）
2.Unrepeatable Read（不可重复读）
3.Phantom Read（幻读）
两类数据更新问题
1.第一类丢失更新
2.第二类丢失更新
首先看看“脏读”，看到“脏”这个字，我就想到了恶心、肮脏。数据怎么可能脏呢？其实也就是我们经常说的“垃圾数据”了。比如说，有两个事务，它们在并发执行（也就是竞争）。看看以下这个表格，您一定会明白我在说什么：
余额应该为 1100 元才对！请看 T6 时间点，事务 A 此时查询余额为 900 元，这个数据就是脏数据，它是事务 A 造成的，明显事务没有进行隔离，渗过来了，乱套了。
所以脏读这件事情是非常要不得的，一定要解决掉！让事务之间隔离起来才是硬道理。
不可重复读又怎么解释呢？还是用类似的例子来说明：
事务 A 其实除了查询了两次以外，其他什么事情都没有做，结果钱就从 1000 变成 0 了，这就是重复读了。可想而知，这是别人干的，不是我干的。其实这样也是合理的，毕竟事务 B 提交了事务，数据库将结果进行了持久化，所以事务 A 再次读取自然就发生了变化。
这种现象基本上是可以理解的，但在有些变态的场景下却是不允许的。毕竟这种现象也是事务之间没有隔离所造成的，但我们对于这种问题，似乎可以忽略。
幻读。我去！Phantom 这个单词不就是“幽灵、鬼魂”吗？刚看到这个单词时，真的把我的小伙伴们都给惊呆了。怪不得这里要翻译成“幻读”了，总不能翻译成“幽灵读”、“鬼魂读”吧。其实意义就是鬼在读，不是人在读，或者说搞不清楚为什么，它就变了，很晕，真的很晕。还是用一个示例来说话吧：
银行工作人员，每次统计总存款，都看到不一样的结果。不过这也确实也挺正常的，总存款增多了，肯定是这个时候有人在存钱。但是如果银行系统真的这样设计，那算是玩完了。这同样也是事务没有隔离所造成的，但对于大多数应用系统而言，这似乎也是正常的，可以理解，也是允许的。银行里那些恶心的那些系统，要求非常严密，统计的时候，甚至会将所有的其他操作给隔离开，这种隔离级别就算非常高了（估计要到 SERIALIZABLE 级别了）。
第一类丢失更新，A事务撤销时，把已经提交的B事务的更新数据覆盖了。这种错误可能造成很严重的问题，通过下面的账户取款转账就可以看出来：
但是，在当前的四种任意隔离级别中，都不会发生该情况，不然绝对乱套，我都没提交事务只是撤销，就把别人的给覆盖了，这也太恐怖了。
第二类丢失更新，B事务覆盖A事务已经提交的数据，造成A事务所做操作丢失
归纳一下，以上提到了事务并发所引起的跟读取数据有关的问题，各用一句话来描述一下：
1.脏读：事务 A 读取了事务 B 未提交的数据，并在这个基础上又做了其他操作。
2.不可重复读：事务 A 读取了事务 B 已提交的更改数据。
3.幻读：事务 A 读取了事务 B 已提交的新增数据。
第一条是坚决抵制的，后两条在大多数情况下可不作考虑。
这就是为什么必须要有事务隔离级别这个东西了，它就像一面墙一样，隔离不同的事务。看下面这个表格，您就清楚了不同的事务隔离级别能处理怎样的事务并发问题：
