事务四大特征：原子性，一致性，隔离性和持久性。
- 原子性（Atomicity）
一个原子事务要么完整执行，要么干脆不执行。这意味着，工作单元中的每项任务都必须正确执行。如果有任一任务执行失败，则整个工作单元或事务就会被终止。即此前对数据所作的任何修改都将被撤销。如果所有任务都被成功执行，事务就会被提交，即对数据所作的修改将会是永久性的。
如果事务无法满足原子性，那么事务必然无法满足一致性。
因为一致性是从逻辑上描述的，原子性是从实现上描述的。
-
一致性（Consistency）
数据与实际业务逻辑一致。 -
隔离性（Isolation）
隔离性意味着事务必须在不干扰其他进程或事务的前提下独立执行。多个同时执行的事务不会因为执行顺序不同导致结果不同。
事务的隔离性有以下几个级别：
- Read Uncommitted：最低的隔离级别，什么都不需要做，相当于没有隔离。一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。
- Read Committed：只有在事务提交后，其更新结果才会被其他事务看见。可以解决脏读问题，即执行一半的事务对其它事务的读操作没有影响。
- Repeated Read：在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。
可重复读，该隔离界别是多次读取同一条记录时，读取结果相同。这是禁止了不可重复读，实质上，当事务A读取记录r1时，不允许其他事务修改 r1，如果修改，需要等待事务A处理结束。说个额外有趣的，当事务A在修改数据时，发生了查询怎么办？实际应用中，是给数据和查询加了一个SCN (System change number)，简单的说，为每一个查询添加一个时间戳，然后对比记录的时间戳。
但是还是有问题，无法解决幻读问题，比如事务A 将 T表 中所有工资不到 10000元 的员工的工资改为10000元，在事务A执行结束尚未提交时，事务B又插入了一条（或删除操作）工资不满10000元的员工记录，然后再提交事务A，事务B。事务A好像发生了幻觉，没有操作成功一样，这是因为“可重复读”锁定的是，已经读取的记录，而不是锁定整张表（或者超出读取范围的数据），可重复读限制了事务本身涉及数据的update行为，但是无法限制事务自身以外的数据。我们可以使用表锁或者范围锁。
- Serialization：事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。
通常，在工程实践中，为了性能的考虑会对隔离性进行折中。
其中只有serialization实现隔离性所有要求，在真正实现事务的隔离性。
但考虑到实践，为了性能，数据库厂商做出了这方面的妥协，让使用者可以选择隔离的级别。
不同的隔离级别可以解决不同阶段的问题，是层层递进，逐渐增强的关系。
隔离性为了解决的问题主要有三个（将事务的隔离级别和问题联系在一起理解）：
1、 脏读(Drity Read)：事务A修改了一个数据，但未提交，事务B读到了事务A未提交的更新结果，如果事务A提交失败，事务B读到的就是脏数据。
Read Committed可以解决脏读问题，但仍存在以下两种问题。
2、不可重复读(Non-repeatable read) : 在同一个事务中，对于同一份数据读取到的结果不一致。比如，事务B在事务A提交前读到的结果，和提交后读到的结果可能不同。不可重复读出现的原因就是事务并发修改记录，要避免这种情况，最简单的方法就是对要修改的记录加锁，这导致锁竞争加剧，影响性能。（另一种方法是通过MVCC可以在无锁的情况下，避免不可重复读。待了解。。）
Repeated Read可以解决不可重复读问题和脏读问题，但仍无法解决下面的问题。
3、幻读(Phantom Read) : 在同一个事务中，同一个查询多次返回的结果不一致。事务A新增了一条记录，事务B在事务A提交前后各执行了一次查询操作，发现后一次比前一次多了一条记录。幻读仅指由于并发事务增加记录导致的问题，这个不能像不可重复读通过记录加锁解决，因为对于新增的记录根本无法加锁。需要将事务串行化，才能避免幻读。
Serialization解决了以上所有问题，但是性能效率较低。
通常来说，事务隔离级别越低，所需持有锁的时间也就越短，并发性能也就越好。
- 持久性（Durability）
持久性表示在某个事务的执行过程中，对数据所作的所有改动都必须在事务成功结束前保存至某种物理存储设备。这样可以保证，所作的修改在任何系统瘫痪时不至于丢失。
