一、事务的4个基本特征
所谓事务是用户定义的一个数据库操作序列,这些操作要么全做要么全不做,是一个不可分割的工作单位。例如,在关系数据库中,一个事务可以是一条SQL语句、一组SQL语句或整个程序。 事务ACID特性。 ACID就是：原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)和持久性(Durabilily)。
事务和程序是两个概念。一般地讲,一个程序中包含多个事务。
事务的开始与结束可以由用户显式控制。如果用户没有显式地定义事务,则由DBMS按缺省规定自动划分事
务。在SQL语言中,定义事务的语句有三条：
BEGIN TRANSACTION
COMMIT
ROLLBACK
同生共死。。
显示事务被用begin transaction 与 end transaction 标识起来，其中的 update 与 delete 语句或者全部执行或者全部不执行。。 如：
begin transaction T1
update student
set name=‘Tank‘
where id=2006010
delete from student
where id=2006011
commit
end transaction T1
简单地说，事务是一种机制，用以维护数据库的完整性。
其实现形式就是将普通的SQL语句嵌入到Begin Tran...Commit Tran 中（或完整形式 Begin Transaction...Commit Transaction)，当然，必要时还可以使用RollBack Tran 回滚事务，即撤销操作。
利用事务机制，对数据库的操作要么全部执行，要么全部不执行，保证数据库的一致性。需要使用事务的SQL语句通常是更新和删除操作等。
一般大家都对事务的四种隔离模式比较熟悉，从松到严依次是：
- 读取未提交(Read uncommitted)：处于此模式下可能会出现脏读、幻象读、不可重复读
- 读取已提交(Read committed)：处于此模式下可能会出现幻象读、不可重复读
- 可重复读(Repeatable read)：处于此模式下可能会出现幻象读
- 串行(Serialize)：不会出现幻象读
那么脏读、幻象行、不可重复读是什么意思呢？
- 脏读：其它的事务（执行单个 select 语句也算一个事务）可以读取到某个事务更新（包括插入和删除）了但未提交的数据。脏读是应用中应该避免的，因为读取的是不可靠的数据（我觉得把这个叫做幻象行更形象，实际却不是）。一般数据库不会设定为这个模式，但有时候也会用到。脏读的好处是读取时不会对表或记录加锁，可以绕开写队列的排队，避免了等待。如在一个更新特别频繁的表中要选择表中所有的数据，就可以显示指定隔离级别：
select .... at isolation 0
- 不可重复读：这是描述在同一个事务中两条一模一样的 select 语句的执行结果的比较。如果前后执行的结果一样，则是可重复读；如果前后的结果可以不一样，则是不可重复读。这个特性从字面上也能看出来。
不可重复读的模式下首先不会出现脏读，即读取的都是已提交的数据。在一个事务中，读取操作是不会加排他锁的，当下一条一模一样的 select 语句的执行时，命中的数据集可能已经被其它事务修改了，这时候，还能读到相同的内容吗？
因此，要达到可重复读的效果，数据库需要做更多的事情，比如，对读取的数据行加共享锁，并保持到事务结束，以禁止其它事务修改它。这样会降低数据库的性能。而隔离级别的串行则比可重复读更严格。一般数据库的的隔离级别只设置到读取已提交。这是兼顾了可靠性和性能的结果。
上面还只提到了对命中的数据行加锁，以防止其它事务修改它。但没有提到，如果其它事务增加了符合条件的数据行怎么办？有些数据库对这种情况新定义了两个级别：读取稳定性和游标稳定性。前者不限制新增符合条件的数据行，而后者则阻止新增这样的数据行。
- 幻象读：是指两次执行同一条 select 语句会出现不同的结果，第二次读会增加一数据行，并没有说这两次执行是在同一个事务中。一般情况下，幻象读应该正是我们所需要的。但有时候却不是，如果打开的游标，在对游标进行操作时，并不希望新增的记录加到游标命中的数据集中来。隔离级别为 游标稳定性 的，可以阻止幻象读。
1、原子性 (Atomicity )
原子性属性用于标识事务是否完全地完成，一个事务的任何更新要在系统上完全完成，如果由于某种原因出错，事务不能完成它的全部任务，系统将返回到事务开始前的状态。
让我们再看一下银行转帐的例子。如果在转帐的过程中出现错误，整个事务将会回滚。只有当事务中的所有部分都成功执行了，才将事务写入磁盘并使变化 永久化。为了提供回滚或者撤消未提交的变化的能力，许多数据源采用日志机制。例如，SQL Server使用一个预写事务日志，在将数据应用于(或提交到)实际数据页面前，先写在事务日志上。但是，其他一些数据源不是关系型数据库管理系统 (RDBMS)，它们管理未提交事务的方式完全不同。只要事务回滚时，数据源可以撤消所有未提交的改变，那么这种技术应该可用于管理事务。
2、一致性( Consistency )
事务在系统完整性中实施一致性，这通过保证系统的任何事务最后都处于有效状态来实现。如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。因为事务开
始时系统处于一致状态，所以现在系统仍然处于一致状态。 再让我们回头看一下银行转帐的例子，在帐户转换和资金转移前，帐户处于有效状态。如果事务成功地完成，并且提交事务，则帐户处于新的有效的状态。如果事务出错，终止后，帐户返回到原先的有效状态。
记住，事务不负责实施数据完整性，而仅仅负责在事务提交或终止以后确保数据返回到一致状态。理解数据完整性规则并写代码实现完整性的重任通常落在 开发者肩上，他们根据业务要求进行设计。 当许多用户同时使用和修改同样的数据时，事务必须保持其数据的完整性和一致性。因此我们进一步研究A C I D特性中的下一个特性：隔离性。
3、隔离性 ( Isolation)
在隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在 系统中认为只有该事务在使用系统。 这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。重要的是，在隔离状态执行事务， 系统的状态有可能是不一致的，在结束事务前，应确保系统处于一致状态。但是在每个单独的事务中，系统的状态可能会发生变化。如果事务不是在隔离状态运行， 它就可能从系统中访问数据，而系统可能处于不一致状态。通过提供事务隔离，可以阻止这类事件的发生。在银行的示例中，这意味着在这个系统内，其他过程和事 务在我们的事务完成前看不到我们的事务引起的任何变化，这对于终止的情况非常重要。如果有另一个过程根据帐户余额进行相应处理，而它在我们的事务完成前就 能看到它造成的变化，那么这个过程的决策可能
建立在错误的数据之上，因为我们的事务可能终止。这就是说明了为什么事务产生的变化，直到事务完成，才对系统的其他部分可见。隔离性不仅仅保 证多个事务不能同时修改相同数据，而且能够保证事务操作产生的变化直到变化被提交或终止时才能对另一个事务可见，并发的事务彼此之间毫无影响。这就意味着 所有要求修改或读取的数据已经被锁定在事务中，直到事务完成才能释放。大多数数据库，例如SQL Server以及其他的RDBMS，通过使用锁定来实现隔离，事务中涉及的各个数据项或数据集使用锁定来防止并发访问。
4、持久性 (Durabilily)
持久性意味着一旦事务执行成功，在系统中产生的所有变化将是永久的。应该存在一些检查点防止在系统失败时丢失信息。甚至硬件本身失败，系统的状态仍能通过在日志中记录事务完成的任务进行重建。持久性的概念允许开发者认为不管系统以后发生了什么变化，完
成的事务是系统永久的部分。 在银行的例子中，资金的转移是永久的，一直保持在系统中。这听起来似乎简单，但这，依赖于将数据写入磁盘，特别需要指出的是，在事务完全完成并提交后才写 入磁盘的。 所有这些事务特性，不管其内部如何关联，仅仅是保证从事务开始到事务完成，不管事务成功与否，都能正确地管理事务涉及的数据 ，当事务处理系统创建事务 时，将确保事务有某些特性。组件的开发者们假设事务的特性应该是一些不需要他们亲自管理的特性。
二、为什么需要对事务并发控制
如果不对事务进行并发控制，我们看看数据库并发操作是会有那些异常情形
1、丢失更新(Lost update)
两个事务都同时更新一行数据，但是第二个事务却中途失败退出，导致对数据的两个修改都失效了。
2、脏读(Dirty Reads)
一个事务开始读取了某行数据，但是另外一个事务已经更新了此数据但没有能够及时提交。这是相当危险的，因为很可能所有的操作都被回滚。
3、非重复读(Non-repeatable Reads)
一个事务对同一行数据重复读取两次，但是却得到了不同的结果。同一查询在同一事务中多次进行，由于其他提交事务所做的修改或删除，每次返回不同的结果集，此时发生非重复读。
4、二类丢失更新(Second lost updates problem)
无法重复读取的特例。有两个并发事务同时读取同一行数据，然后其中一个对它进行修改提交，而另一个也进行了修改提交。这就会造成第一次写操作失效。
5、幻像读(Phantom Reads)
事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查
询中未出现的数据（这里并不要求两次查询的SQL语句相同）。这是因为在两次查询过程中有另外一个事务插入数据造成的。
三、数据库的隔离级别
为了兼顾并发效率和异常控制，在标准SQL规范中，定义了4个事务隔离级别，（ORACLE和SQLSERER对标准隔离级别有不同的实现 ）
1、未提交读(Read Uncommitted)
直译就是"读未提交",意思就是即使一个更新语句没有提交,但是别
的事务可以读到这个改变.这是很不安全的。允许任务读取数据库中未提交的数据更改，也称为脏读。
2、提交读(Read Committed)
直译就是"读提交",可防止脏读，意思就是语句提交以后即执行了COMMIT以后
别的事务就能读到这个改变. 只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别
3、可重复读(Repeatable Read)：
直译就是"可以重复读",这是说在同一个事务里面先后执行同一个查询语句的时候,得到的结果是一样的.在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读
4、串行读(Serializable)
直译就是"序列化",意思是说这个事务执行的时候不允许别的事务并发执行. 完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞
四，隔离级别对事务并发的控制
下表是各隔离级别对各种异常的控制能力。
| LU丢失更新 | DR脏读 | NRR非重复读 | SLU二类丢失更新 | PR幻像读 | |
| 未提交读 RU | Y | Y | Y | Y | Y |
| 提交读 RC | N | N | Y | Y | Y |
| 可重复读 RR | N | N | N | N | Y |
| 串行读 S | N | N | N | N | N |
顺便举一小例。
My_SQL:
--事务一
set transaction isolation level serializable
begin tran
insert into test values(‘xxx‘)
--事务二
set transaction isolation level read committed
begin tran
select * from test
--事务三
set transaction isolation level read uncommitted
begin tran
select * from test
在查询分析器中执行事务一后，分别执行事务二，和三。结果是事务二会等待，而事务三则会执行。
ORACLE：
--事务一
set transaction isolation level serializable;
insert into test values(‘xxx‘);
select * from test;
--事务二
set transaction isolation level read committed--ORACLE默认级别
select * from test
执行事务一后，执行事务二。结果是事务二只读出原有的数据，无视事务一的插入操作。
五、并发一致性问题的解决办法
1 封锁（Locking）
封锁是实现并发控制的一个非常重要的技术。所谓封锁就是事务T在对某个数据对象例如表、记录等操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该 数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象。 基本的封锁类型有两种：排它锁（Exclusive locks 简记为X锁）和共享锁（Share locks 简记为S锁）。
排它锁又称为写锁。若事务T对数据对象A加上X锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。这就保证了其它事务在T释放A上的锁之前不能再读取和修改A。
共享锁又称为读锁。若事务T对数据对象A加上S锁，则其它事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这就保证了其它事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
2 封锁协议
在 运用X锁和S锁这两种基本封锁，对数据对象加锁时，还需要约定一些规则，例如应何时申请X锁或S锁、持锁时间、何时释放等。我们称这些规则为封锁协议 （Locking Protocol）。对封锁方式规定不同的规则，就形成了各种不同的封锁协议。下面介绍三级封锁协议。三级封锁协议分别在不同程度上解决了丢失的修改、不 可重复读和读"脏"数据等不一致性问题，为并发操作的正确调度提供一定的保证。下面只给出三级封锁协议的定义，不再做过多探讨。
1 级封锁协议是：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。 1级封锁协议可防止丢失修改，并保证事务T是可恢复的。在1级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，所以它不能保证可重复读和不 读"脏"数据。
2级封锁协议是：1级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。2级封锁协议除防止了丢失修改，还可进一步防止读"脏"数据。
3级封锁协议是：1级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。3级封锁协议除防止了丢失修改和不读‘脏‘数据外，还进一步防止了不可重复读。
六、一般处理并发问题时的步骤：
1、开启事务。
2、申请写权限，也就是给对象(表或记录)加锁。
3、假如失败，则结束事务，过一会重试。
4、假如成功，也就是给对象加锁成功，防止其他用户再用同样的方式打开。
5、进行编辑操作。
6、写入所进行的编辑结果。
7、假如写入成功，则提交事务,完成操作。
8、假如写入失败，则回滚事务，取消提交。
9、(7.8)两步操作已释放了锁定的对象，恢复到操作前的状态。
锁和隔离级别的关系
一般来说，实际开发中，直接操作数据库中各种锁的几率相对比较少，更多的是利用数据库提供的四个隔离级别，未提交读、已提交读、可重复读、可序列化，那隔离级别和锁是什么关系？通俗来说，隔离级别是锁的一个整体打包解决方案，我的理解是隔离封装了锁。
隔离级别从上到下依次增加，级别越低，引起的问题也就比较多，比如脏读、丢失更新等，但等级越高，也就意味着需要管理更多的锁，无法并行处理，性能方面又受损，因此，我们在设计系统时，只需要根据业务需求选择一种当下适合的隔离级别。一种隔离级别，就有一套利用锁的方案，如此设计，目的就是为了平衡性能和功能。
独占锁可以进行读但不能进行其他操作，事务设置排它锁后，该事务单独获得此资源，另一事务不能在此事务提交之前获得相同对象的共享锁或排它锁
原文地址：https://www.cnblogs.com/lgx-fighting/p/9379239.html