开篇介绍
原本打算写有关 SSIS Package 中的事务控制过程的，但是发现很多基本的概念还是需要有 SQL Server 事务和事务的隔离级别做基础铺垫。所以花了点时间，把 SQL Server 数据库中的事务概念、ACID 原则、事务中常见的问题、问题造成的原因和事务隔离级别等这些方面的知识好好的整理了一下。
其实有关 SQL Server 中的事务，说实话因为内容太多, 话题太广，稍微力度控制不好就超过了我目前知识能力范围，就不是三言两语能够讲清楚的。所以希望大家能够指出其中总结的不足之处，对我来说多了提高的机会，更可以帮助大家加深对事务的理解。
本文涉及到的知识点
- SQL Server 数据库中事务的概念
- ACID 原则 (加了一部分内容专门解释原子性，提到了显示事务以及 XACT_ABORT 机制来确保事务的原子性)
- 列出事务中常见的问题以及原因：脏读，未提交读，不可重复读，幻读 等
- SQL Server中 事务的隔离级别以及它们如何做到避免脏读，未提交读，不可重复读和幻读 (用代码描述了这些问题，并且使用时间序来解释产生的原因)
SQL Server 数据库中事务的概念
数据库中的事务是数据库并发控制的基本单位，一条或者一组语句要么全部成功，对数据库中的某些数据成功修改; 要么全部不成功，数据库中的数据还原到这些语句执行
之前的样子。比如网上订火车票，要么你定票成功，余票显示就减一张; 要么你定票失败获取取消订票，余票的数量还是那么多。不允许出现你订票成功了，余票没有减少或者你取消订票了，余票显示却少了一张的这种情况。这种不被允许出现的情况就要求购票和余票减少这两个不同的操作必须放在一起，成为一个完整的逻辑链，这样就构成了一个事务。
数据库中事务的 ACID 原则
原子性 (Atomicity)：事务的原子性是指一个事务中包含的一条语句或者多条语句构成了一个完整的逻辑单元，这个逻辑单元具有不可再分的原子性。这个逻辑单元要么一起提交执行全部成功，要么一起提交执行全部失败。
一致性 (Consistency)：可以理解为数据的完整性，事务的提交要确保在数据库上的操作没有破坏数据的完整性，比如说不要违背一些约束的数据插入或者修改行为。一旦破坏了数据的完整性，SQL Server 会回滚这个事务来确保数据库中的数据是一致的。
隔离性(Isolation)：与数据库中的事务隔离级别以及锁相关，多个用户可以对同一数据并发访问而又不破坏数据的正确性和完整性。但是，并行事务的修改必须与其它并行事务的修改相互独立，隔离。 但是在不同的隔离级别下，事务的读取操作可能得到的结果是不同的。
持久性(Durability)：数据持久化，事务一旦对数据的操作完成并提交后，数据修改就已经完成，即使服务重启这些数据也不会改变。相反，如果在事务的执行过程中，系统服务崩溃或者重启，那么事务所有的操作就会被回滚，即回到事务操作之前的状态。
我理解在极端断电或者系统崩溃的情况下，一个发生在事务未提交之前，数据库应该记录了这个事务的"ID"和部分已经在数据库上更新的数据。供电恢复数据库重新启动之后，这时完成全部撤销和回滚操作。如果在事务提交之后的断电，有可能更改的结果没有正常写入磁盘持久化，但是有可能丢失的数据会通过事务日志自动恢复并重新生成以写入磁盘完成持久化。
原子性的进一步理解
关于原子性，有必要在这里多补充一下，因为我们描述的概念是指在事务中的原子性。一条 SQL 语句和多条 SQL 语句在处理原子性上是有一些区别的，下面演示了这些区别。
先运行这些代码，创建一个非常简单的测试表，这张表只简单模拟了一个账户的 ID 和账户余额。
USE BIWORK_SSIS
GO
IF OBJECT_ID('dbo.Account') IS NOT NULL
DROP TABLE dbo.Account
GO
CREATE TABLE dbo.Account
(
ID INT PRIMARY KEY,
AccountBalance MONEY CHECK(AccountBalance >= 0)
)单条 SQL 语句的原子性
插入一条测试语句，然后再查询一下结果。
这里提到了自动提交事务，这时 T-SQL 默认的事务方式，它是一种能够自动执行并能够自动回滚事务的处理方式。SQL Server 除了自动提交事务之外，还有显示事务和隐式事务，暂时不在这篇文章中讨论它们的区别了。
上面的两个自动提交事务中，每一个自动提交事务只包含一条 SQL 语句，不能再分，要么成功，要么失败。
再比如，在一条 SQL 语句中插入多条数据时，其中一条数据是符合约束的。但因为另外一条数据违反了检查约束，这样也会导致整个 Insert 语句失败，因此没有一条数据能够插入到数据表中。
多条 SQL 语句形成的一个整体的原子性
假设下面的这两条 Insert 语句构成一个具备原子性特征的逻辑单元，是一个整体需要形成一个事务，那么应该如何处理。
INSERT INTO dbo.Account VALUES(1004,-1)
INSERT INTO dbo.Account VALUES(1005,500)很显然如果直接这么执行的话，1004 插入失败，1005 可以插入成功，这样就是两个不同的事务了。
SQL Server 提供了两种方式来确保这种包含多组 SQL 语句的逻辑块具备原子性特征。
方式一 - 使用显示事务组合多条 SQL 语句构成一个整体以实现事务的原子性
第一种就是非常常见的显示事务，通过显示的使用 BEGIN TRANSACTION, COMMIT TRANSACTION 以及 ROLLBACK TRANSACTION 命令将一组 SQL 语句形成一个完整的事务来提交，提交要么成功，要么失败。
-- 开始一个事务
BEGIN TRANSACTION
-- TRY CATCH 语句
BEGIN TRY
-- 这一条会违反检查约束，插入失败
INSERT INTO dbo.Account VALUES(1004,-1)
-- 这一条会插入成功，但此时事务还未真正提交
INSERT INTO dbo.Account VALUES(1005,500)
END TRY
BEGIN CATCH
-- 发生错误，事务回滚
IF @@TRANCOUNT > 0
ROLLBACK TRANSACTION;
END CATCH;
-- 没有进入 CATCH 块，提交事务
IF @@TRANCOUNT > 0
COMMIT TRANSACTION;
GO当然最终的结果就是事务回滚，一条数据都没有插入到数据表中，所以失败时就全部失败，确保了事务的原子性。
方式二 - 通过设置 XACT_ABORT 为 ON 来确保事务的原子性
先来看默认的设置，当 XACT_ABORT 为 OFF 状态的时候。
-- SET XACT_ABORT OFF - 默认的 SQL Server 设置
SET XACT_ABORT OFF
BEGIN TRANSACTION
-- 这一条会违反检查约束，插入失败
INSERT INTO dbo.Account VALUES(1004,-1)
-- 这一条会插入成功
INSERT INTO dbo.Account VALUES(1005,500)
COMMIT TRANSACTION当 XACT_ABORT 为 OFF 状态即 SQL Server 默认设置下，上面的事务中，SQL Server 在通常情况下只会回滚执行失败的语句，也就是说只会回滚 1004 这条数据，而 1005 会插入成功。很显然，这违背了事务的原子性，因为我们也没有显示的写出要 ROLLBACK TRANSACTION 来。
OK！那我们将 XACT_ABORT 设置为 ON，这时就告诉了它后面的事务，如果遇到错误就立即终止事务并回滚。这样不通过显示的 ROLLBACK TRANSACTION 也可以确保事务的原子性。
在上面的这个例子中，只有事务 2 会成功提交，而事务1和3会回滚，插入操作执行失败。
注意一点，上面的每个事务后面加了一个 GO 关键字，如果不加 GO 这个关键字，一起执行这些 SQL 语句会导致事务2和3因为事务1的执行失败而不能执行到, GO 关键字形成了一个批处理，表示前面的一组 SQL 语句一起处理。
GO 关键字非常有意思，GO 后面可以加上次数，表示前面的一条或者一组 SQL 执行几次。
通过上面的示例，应该可以理解原子性与事务的关系了，以及如何实现事务的原子性。
事务中常见的问题
了解完事务的 ACID 的原则后，再来看看在 SQL Server 中多用户并发的情况下，使用事务可能会遇到的一些情况：
脏读 (Dirty Reads) : 一个事务正在访问并修改数据库中的数据但是没有提交，但是另外一个事务可能读取到这些已作出修改但未提交的数据。这样可能导致的结果就是所有的操作都有可能回滚，比如第一个事务对数据做出的修改可能违背了数据表的某些约束，破坏了完整性，但是恰巧第二个事务却读取到了这些不正确的数据造成它自身操作也发生失败回滚。
不可重复读取(Non-Repeatable Reads): A 事务两次读取同一数据，B事务也读取这同一数据，但是 A 事务在第二次读取前B事务已经更新了这一数据。所以对于A事务来说，它第一次和第二次读取到的这一数据可能就不一致了。
幻读(Phantom Reads): 与不可重复读有点类似，都是两次读取，不同的是 A 事务第一次操作的比如说是全表的数据，此时 B 事务并不是只修改某一具体数据而是插入了一条新数据，而后 A 事务第二次读取这全表的时候就发现比上一次多了一条数据，发生幻觉了。
更新丢失(Lost Update): 两个事务同时更新，但由于某一个事务更新失败发生回滚操作，这样有可能的结果就是第二个事务已更新的数据因为第一个事务发生回滚而导致数据最终没有发生更新，因此两个事务的更新都失败了。
SQL Server 中事务的隔离级别以及与脏读、不可重复读、幻读等关系(代码论证和时间序)
了解了在并发访问数据库的情况下可能会出现这些问题，就可以继续了解数据库隔离级别这样的一个概念，通俗一点讲就是：你希望通过何种方式让并发的事务隔离开来，隔离到什么程度？比如可以容忍脏读，或者不希望并发的事务出现脏读的情况，那么这些可以通过隔离级别的设置使得并发事务之间的隔离程度变得宽松或者很严峻。
隔离级别越高，读取脏数据或者造成数据不统一不完整的机会就越少，但是在高并发的系统中，性能降低就越严重。隔离级别越低，并发系统中性能上提升很大，但是数据本身可能不完整。
在 SQL Server 2012 中可以通过这样的语法来设置事务的隔离级别 (从低到高排列)：
SET TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED
| READ COMMITTED
| REPEATABLE READ
| SNAPSHOT
| SERIALIZABLE
}
[ ; ]下面通过代码示例来演示各个事务隔离级别的表现，运行下面 SQL 语句，插入一条测试语句。
TRUNCATE TABLE BIWORK_SSIS.dbo.Account
GO
INSERT INTO BIWORK_SSIS.dbo.Account VALUES(1001,1000)
SELECT * FROM BIWORK_SSIS.dbo.Account
GORead Uncommitted (未提交读)
隔离级别最低，容易产生的问题就是脏读，因为可以读取其它事务修改了的但是没有提交的数据。它的作用跟在事务中 SELECT 语句对象表上设置 (NOLOCK) 相同。
打开两个查询窗口，第一个窗口表示事务 A， 第二个窗口表示事务B。 事务A 保持默认的隔离级别，事务B 设置它们的隔离级别为 READ UNCOMMITTED， 可以通过 DBCC USEROPITIONS 查看更改后的结果。
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
DBCC USEROPTIONS测试步骤：
先执行事务 A 的 SQL 代码
BEGIN TRANSACTION
UPDATE BIWORK_SSIS.dbo.Account
SET AccountBalance = 500
WHERE ID = 1001
WAITFOR DELAY '00:00:10'
ROLLBACK TRANSACTION
SELECT * FROM BIWORK_SSIS.dbo.Account WHERE ID = 1001马上接着再执行 事务 B 的 SQL 代码
-- 第1次查询 发生在 A 事务未提交或者回滚之前
SELECT * FROM BIWORK_SSIS.dbo.Account WHERE ID = 1001
WAITFOR DELAY '00:00:10'
-- 第2次查询 发生在 A 事务回滚之后
SELECT * FROM BIWORK_SSIS.dbo.Account WHERE ID = 1001
可以看出，事务 B 对 ID = 1001 的这条数据进行了两次读取，但是很显然第一次读取的数据是脏数据。下面模拟了一下它们发生的时序，虽然不算严谨，但是可以帮助理解脏读产生的原因。
还可以把事务B 的隔离级别改回来成为默认的 READ COMMITTED，然后运行完事务 A 之后马上运行带有 NOLOCK 的查询，效果和上面描述的也是一致的。 一旦加上 NOLOCK，可以认为它的作用就等同于隔离级别为 READ UNCOMMITTED。
SELECT * FROM BIWORK_SSIS.dbo.Account WITH(NOLOCK) WHERE ID = 1001Read Committed (已提交读)
这是 SQL Server 的默认设置，已提交读，可以避免脏读，可以满足大多数要求。事务中的语句不能读取已由其它事务做出修改但是还未提交的数据，但是能够读取由其它事务做出修改并提交了的数据。也就是说，有可能会出现 Non-Repeatable Reads 不可重复读取和 Phantom Reads 幻读的情况，因为当前事务中可能出现两次读取同一资源，但是两次读取的过程之间，另外一事务可能对这一资源完成了读取更新并提交的行为，这样数据前后可能就不一致了。因此，这一个默认的隔离级别能够解决脏读但是解决不了 Non-Repeatable Reads 不可重复读。
接着上一个例子，看看如果将隔离级别设置为 READ COMMITTED，能否避免脏读？ 还是先运行事务 A，再接着运行事务 B。
因为已提交读不能读取已由其它事物做出修改但是还未提交的数据，因此事务B 就必须等待事务 A 完成对数据的修改提交或者回滚之后才能开始读取。运行事务A 和事务B，明显事务B 有一个等待事务A提交或者回滚的过程，看看它们的时序图。
由此可以看出隔离级别 READ COMMITTED 可以避免脏读，但是也有可能出现其它的问题，请看这个例子。先执行事务A，接着直接执行事务 B。
从上面的执行结果来看，很明显在事务 A 中，同一个事务中对 ID = 1001 的取值出现了前后不一致的情况。假设这里不是简单的查询，而是先查询账户余额有 1000元钱，然后后面的动作就是取 1000元钱，很明显第二次取的时候发现只有 500 元了。原因就是在第一次查询和取的间隙之间被事务 B 钻了空子，修改了余额。这种情况就是上面所介绍到的不可重复读取，请看下面的时序图。
所以 READ COMMITTED 已提交读隔离级别能够避免脏读，但是仍然会遇到不可重复读取的问题。
Repeatable Read (可重复读)
不能读取已由其它事务修改了但是未提交的行，其它任何事务也不能修改在当前事务完成之前由当前事务读取的数据。但是对于其它事务插入的新行数据，当前事务第二次访问表行时会检索这一新行。因此，这一个隔离级别的设置解决了 Non-Repeatable Reads 不可重复读取的问题，但是避免不了 Phantom Reads 幻读。
接着上面的例子做出一些修改，增加了一些查询，记得把 ID = 1001 的余额改回 1000。将事务 A 的隔离级别设置为 REPEATABLE READ 可重复读级别，来看看这个隔离级别的表现。
尽管在最后的查询结果中， ID = 1001 的余额为 500 元，但是在事务 A 中的两次读取一次发生在 事务 B 开始之前，一次发生在 事务 B 提交之后，但是它们读取的余额是保持一致的，看不到事务 B 对这个值的修改。
从上面的时序图中可以看出，事务 A 第一次读取到的 ID = 1001 的余额值和第二次读取到的是一样的，可以理解为在事务 A 的查询期间是不允许事务 B 修改这个值的。 因为事务 A 确实没有看到这个变化，所以事务A 也确实认为事务B 听了它的话，没有做出 Update 的操作。但是实际上，事务 B 已经完成了这个操作，只不过由于 事务 A 中隔离级别设置为 REPEATABLE READ 可重复读，所以两次读取的结果始终保持着一致。
那么这里的示例是事务B在修改数据，如果是新增加一行记录呢？
事务 A 又开始晕菜了！居然两次查询的结果不一样，第二次查询多了一条数据，这就是幻读！
SNAPSHOT (快照隔离)
可以解决幻读 Phantom Reads 的问题，当前事务中读取的数据在整个事务开始到事务提交结束之间，这个数据版本是一致的。其它的事务可能对这些数据做出修改，但是对于当前事务来说它是看不到这些变化。有点类似于当前事务拿到这个数据的时候是拿到这个数据的快照，因此在这个快照上做出的操作同一事务中前后几次操作都是基于同一数据版本。因此，这一个隔离级别的设置可以解决 Phantom Reads 幻读问题。但是要注意的是，其它事务是可以在当前事务完成之前修改由当前事务读取的数据。
在使用 SNAPSHOT 之前要注意，默认情况下数据库不允许设置 SNAPSHOT 隔离级别，直接设置会出现类似于这样的错误：
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Msg 3952, Level 16, State 1, Line 8
Snapshot isolation transaction failed accessing database 'BIWORK_SSIS' because snapshot isolation is not allowed in this database. Use ALTER DATABASE to allow snapshot isolation.
所以要使用 SET 命令开启这个支持
ALTER DATABASE BIWORK_SSIS
SET ALLOW_SNAPSHOT_ISOLATION ON并且在开始前先清空其它的 ID，只保留 ID = 1001 的这条记录。
DELETE FROM BIWORK_SSIS.dbo.Account
WHERE ID <> 1001
这样通过设置隔离级别是 SNAPSHOT就解决了幻读的问题，保证了在事务 A 中查询的数据行版本是前后一致的。
但是大家发现没有？无论在事务 A 中使用 Repeatable Read 还是 Snapshot 仍然不可避免的阻止事务B 对共享的资源做出了修改，尽管这个修改没有被事务 A 发现，事务 A 中的数据还是保持了一致，但是实际上还是做出了修改。只要事务 A 一提交结束，马上就可以看到事务 B 做出的这些修改已经生效了。回顾之前提到的，如果我第一次查询有1000元，第二次动作可能就是取1000元。在这两次动作之间另外的一个事务对金额做出了修改，尽管我两次读取都是1000元，但是实际上是不符合常理的。要么，我先查询然后再取款这个动作是连贯的，然后另外一个事务再对金额做出修改。要么，其它事务先对金额做出修改，比如扣去500元，那么我再查询再取款这个钱数还是一致的。也就是说，在事务 A 对某一个资源做出操作的时候，形成了独占，事务 B 进不来。或者事务 B 在对这个资源做操作的时候，事务 A 也必须等待事务 B 结束后才能开始它的事务，那么这里就要使用到最严格的隔离级别了 - SERIALIZABLE。
SERIALIZABLE(序列化)
性能最低，隔离级别最高最严格，可以几乎上面提到的所有问题。比如不能读取其它已由其它事务修改但是没有提交的数据，不允许其它事务在当前事务完成修改之前修改由当前事务读取的数据，不允许其它事务在当前事务完成修改之前插入新的行。它的作用与在事务内所有 SELECT 语句中的所有表上设置 HOLDLOCK 相同，并发级别比较低但又对安全性要求比较高的时候可以考虑使用。如果并发级别很高，使用这个隔离级别，性能瓶颈将非常严重。
将事务 A 的隔离级别调整成 SERIALIZABLE，然后执行 A 然后再执行 B。
在这里可以看到事务B 的执行基本上是在事务A提交之后才开始的，当事务 A 在执行的时候，事务 B 因为也要访问这个资源所以一直阻塞在那里直到事务 A 提交。 并不是说事务 B 没有开始，而是说在执行 SELECT 查询的时候因为事务 A 占用了这个资源，所以处于等待状态。
在 SQL Server 中设置隔离级别要注意：一次只能设置一个隔离级别的选项，并且设置的隔离级别对当前连接一直有效直到显式修改为止。事务中执行的所有读取操作也都会在指定的隔离级别规则下运行，除非在 SELECT 操作语句中对表指定了其它的锁或者版本控制行为。
注：上面的时序图只是用来帮助理解事务的隔离级别，只是一个大概的执行顺序，当然也跟我执行事务 A 和 事务 B 的时间点相关，所以并不能真正反映实际过程中 SQL 语句提交和执行的实际顺序，真正提交的过程可以通过 SQL Profiler 去跟踪看看。