数据库事务和锁

 

简述

    关系型数据库有四个显著的特征，即安全性、完整性、并发性和监测性。数据库的安全性就是要保证数据库中数据的安全，防止未授权用户随意修改数据库中的数据，确保数据的安全。在大多数数据库管理系统中，主要是通过许可来保证数据库的安全性。完整性是数据库的一个重要特征，也是保证数据库中的数据切实有效、防止错误、实现商业规则的一种重要机制。在数据库中，区别所保存的数据是无用的垃圾还是有价值的信息，主要是依据数据库的完整性是否健全。在SQL Server 7.0中，数据的完整性是通过一系列逻辑来保障的，这些逻辑分为三个方面，即实体完整性、域完整性和参考完整性。对任何系统都可以这样说，没有监测，就没有优化。这句话用在数据库管理系统方面，也是切合实际的。只有通过对数据库进行全面的性能监测，也才能发现影响系统性能的因素和瓶颈，才能针对瓶颈因素，采取切合实际策略，解决问题，提高系统的性能。并发性也是一个非常重要的概念，它是用来解决多个用户对同一数据进行操作时的问题。特别是对于网络数据库来说，这个特点更加突出。提高数据库的处理速度，单单依靠提高计算机的物理速度是不够的，还必须充分考虑数据库的并发性问题，提高数据库并发性的效率。那么如何保证并发性呢？在这个面向下一世纪的数据库产品SQL Server 7.0中，通过使用事务和锁机制，解决了数据库的并发性问题。

概念和特点

事务和锁是两个紧密联系的概念。事务就是一个单元的工作，包括一系列的操作这些操作要么全部成功，要么全部失败。事务确保多个数据的修改作为一个单元来处理。例如，在银行业务中，有一条记帐原则，即有借有贷，借贷相等。那么为了保证这种原则，就得有确保借和贷的登记要么同时成功，要么同时失败。如果出现只记录了借，或者只记录了贷，那么就违反了记帐原则，就会出现记错帐的情况。SQL Server通过支持事务机制管理多个事务，保证事务的一致性。事务使用锁，防止其他用户修改另外一个还没有完成的事务中的数据。对于多用户系统来说，锁机制是必须的。在SQL Server 7.0中，使用事务日志来保证修改的完整性和可恢复性。

    SQL Server有多种锁，允许事务锁定不同的资源。锁就是保护指定的资源，不被其他事务操作。为了最小化锁的成本，SQL Server自动地以与任务相应等级的锁来锁定资源对象。锁定比较小的对象，例如锁定行，虽然可以提高并发性，但是却有较高的开支，因为如果锁定许多行，那么需要占有更多的锁。锁定比较大的对象，例如锁定表，会大大降低并发性，因为锁定整个表就限制了其他事务访问该表的其他部分，但是成本开支比较低，因为只需维护比较少的锁。

    事务和锁具有以下特点:

事务是一个单元的工作，要么全做，要么全不做

事务保证操作的一致性和可恢复性

每一条Transact-SQL语句都可以是一个事务

实际使用的事务是用户定义的事务，它包括一系列操作或者语句

在多服务器环境中，使用用户定义的分布式事务，保证操作的一致性

锁是保证并发控制的手段

可以锁定的资源包括行、页、簇、表和数据库

锁的类型主要包括共享锁和排它锁

特殊类型的锁包括意图锁、修改锁和模式锁

共享锁允许其他事务继续使用锁定的资源

排它锁只允许一个事务访问数据

系统本身可以处理死锁

用户可以根据实际情况定制锁的一些特征

事务

事务的定义

    事务是指一个单元的工作，这些工作要么全做，要么全部不做。作为一个逻辑单元，必须具备四个属性：自动性、一致性、独立性和持久性。自动性是指事务必须是一个自动的单元工作，要么执行全部数据的修改，要么全部数据的修改都不执行。一致性是指当事务完成时，必须使所有数据都具有一致的状态。在关系型数据库中，所有的规则必须应用到事务的修改上，以便维护所有数据的完整性。所有的内部数据结构，例如树状的索引与数据之间的链接，在事务结束之后，必须保证正确。独立性是指并行事务的修改必须与其他并行事务的修改相互独立。一个事务看到的数据要么是另外一个事务修改这些事务之前的状态，要么是第二个事务已经修改完成的数据，但是这个事务不能看到正在修改的数据。这种特征也称为串行性。持久性是指当一个事务完成之后，它的影响永久性的产生在系统中，也就是这种修改写到了数据库中。

    事务机制保证一组数据的修改要么全部执行，要么全部不执行。SQL Server使用事务保证数据的一致性和确保在系统失败时的可恢复性。事务是一个可以恢复的单元的工作，由一条或者多条Transact-SQL语句组成，可以影响到表中的一行或者多行数据。事务打开以后，直到事务成功完成之后提交为止，或者到事务执行失败全部取消或者滚回去为止。

数据库事务和锁（二）

事务的工作原理图

事务确保数据的一致性和可恢复性。事务的工作原理如图1所示。

图1   事务的工作原理图

    事务开始之后，事务所有的操作都陆续写到事务日志中。写到日志中的操作，一般有两种：一种是针对数据的操作，一种是针对任务的操作。针对数据的操作，例如插入、删除和修改，这是典型的事务操作，这些操作的对象是大量的数据。有些操作是针对任务的，例如创建索引，这些任务操作在事务日志中记录一个标志，用于表示执行了这种操作。当取消这种事务时，系统自动执行这种操作的反操作，保证系统的一致性。系统自动生成一个检查点机制，这个检查点周期地发生。检查点的周期是系统根据用户定义的时间间隔和系统活动的频度由系统自动计算出来的时间间隔。检查点周期地检查事务日志，如果在事务日志中，事务全部完成，那么检查点将事务日志中的事务提交到数据库中，并且在事务日志中做一个检查点提交标记。如果在事务日志中，事务没有完成，那么检查点将事务日志中的事务不提交到数据库中，并且在事务日志中做一个检查点未提交标记。事务的恢复以及检查点保护系统的完整和可恢复，可以使用如图2所示的示例说明。

图2   事务恢复和检查点示例

    在这个示例图中，有五个事务：事务1、事务2、事务3、事务4和事务5。方框表示事务的开始和完成提交。水平方向表示时间。检查点表示在某一时间点发生检查点机制，系统失败表示在某一时间点由于断电、系统软件失败等原因而发生的系统失败。事务1的完成发生在检查点发生之间，所以事务1被提交到数据库中。事务2和事务4的完成发生在系统失败之前，所以这两个事务可以被系统向前滚动提交到数据库中。事务3和事务5由于系统失败而没有完成，所以这两个事务被取消。

数据库事务和锁（三）

使用事务的考虑

在使用事务时，原则上应该使事务尽可能得短并且要避免事务嵌套。事务应该尽可能得短，这是因为比较长的事务增加了事务占用数据的时间，使其它必须等待访问该事务锁定数据的事务，延长了等待访问数据的时间。在使用事务时，为了使事务尽可能得短，应该采取一些相应的方法。为了最小化时间，在使用一些Transact-SQL语句时，一定要非常小心。例如，当使用循环语句WHILE时，一定要事先确认循环的长度和占用的时间，使这种循环在完成相应的功能之前，一定要确保循环尽可能得短。在开始事务之前，一定要了解需要用户交互式操作才能得到的信息。这样，在事务的进行过程中，就可以避免进行一些耗费时间的交互式操作，缩短事务进程的时间。在一个用户定义的事务中，应该尽可能地使用一些数据操纵语言，例如INSERT、UPDATE和DELETE语句，因为这些语句主要是操纵数据库中的数据。而对于一些数据定义语言，应该尽可能地少用或者不用，因为这些数据定义语言的操作既占用比较长的时间，又占用比较多的资源，并且这些数据定义语言的操作通常不涉及到数据，所以应该在事务中尽可能地少用或者不用这些操作。另外，在使用数据操纵语言时，要注意，一定要在这些语句中使用条件判断语句，使得这些数据操纵语言涉及到尽可能少的记录，从而缩短事务的处理时间。

在嵌套事务时，也要注意一些问题。虽然说，在事务中间嵌套事务是可能的，并不影响SQL Server处理事务的性能。但是，实际上，使用嵌套事务，除了把事务搞得更加复杂之外，并没有这么明显的好处。因此，不建议使用嵌套事务。

事务的类型

根据系统的设置，可以把事务分成两种类型。一种是系统提供的事务，另一种是用户定义的事务。系统提供的事务是指在执行某些语句时，一条语句就是一个事务。这时要明确，一条语句的对象既可能是表中的一行数据，也可能是表中的多行数据，甚至是表中的全部数据。因此，只有一条语句构成的事务也可能包含了多行数据的处理。例如执行下面这条数据操纵语句：

UPDATE  authors

SET state = ‘CA’

这是一条语句，这条语句本身就构成了一个事务。这条语句由于没有使用条件限制，那么这条语句就是修改表中的全部数据。所以这个事务的对象，就是修改表中的全部数据。如果authors表中有1000行数据，那么这1000行数据的修改要么全部成功，要么全部失败。

另外一种事务，是用户明确定义的事务。在实际应用中，大多数的事务处理就是采用了用户定义的事务来处理。在开发应用程序时，可以使用BEGIN TRANSACTION语句来定义明确的用户定义的事务。在使用用户定义的事务时，一定要注意两点：一是事务必须有明确的结束语句来结束。如果不使用明确的结束语句来结束，那么系统可能把从事务开始到用户关闭连接之间的全部操作都作为一个事务来对待。事务的明确结束可以使用这样两个语句中的一个：COMMIT语句和ROLLBACK语句。COMMIT语句是提交语句，将全部完成的语句明确地提交到数据库中。ROLLBACK语句是取消语句，该语句将事务的操作全部取消，即表示事务操作失败。

还有一种特殊的用户定义的事务，这就是分布式事务。前面提到的事务都是在一个服务器上的操作，其保证的数据完整性和一致性是指一个服务器上的完整性和一致性。但是，如果一个比较复杂的环境，可能有多台服务器，那么要保证在多服务器环境中事务的完整性和一致性，就必须定义一个分布式事务。在这个分布式事务中，所有的操作都可以涉及对多个服务器的操作，当这些操作都成功时，那么所有这些操作都提交到相应服务器的数据库中，如果这些操作中有一条操作失败，那么这个分布式事务中的全部操作都被取消。

锁和锁的作用

锁就是防止其他事务访问指定的资源的手段。锁是实现并发控制的主要方法，是多个用户能够同时操纵同一个数据库中的数据而不发生数据不一致现象的重要保障。一般来说，锁可以防止脏读、不可重复读和幻觉读。脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。不可重复读是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。幻觉读是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。

数据库事务和锁（四）

空间管理

    锁是防止其他事务访问指定的资源控制、实现并发控制的一种主要手段。为了提高系统的性能，加快事务的处理速度，缩短事务的等待时间，应该使锁定的资源最小化。为了控制锁定的资源，应该首先了解系统的空间管理。在SQL Server系统中，最小的空间管理单位是页，一个页有8K。所有的数据、日志、索引都存放在页上。另外，使用页有一个限制，这就是表中的一行数据必须在同一个页上，不能跨页。页上面的空间管理单位是簇，一个簇是8个连续的页。表和索引的最小占用单位是簇。数据库是由一个或者多个表或者索引组成，即是由多个簇组成。SQL Server系统的空间管理结构示意图如图3所示。

图3  SQL Server空间管理

可以锁定的资源

为了优化系统的并发性，应该根据事务的大小和系统活动的程度，锁定不同的资源。也就是说，既可以锁定比较大的资源，也可以锁定比较小的资源。在SQL Server系统中，已经比较完善地实现了这些要求。在SQL Server 7.0中，可以锁定的资源有多种，这些可以锁定的资源分别是行、页、簇、表和数据库，他们对应的锁分别是行级锁、页级锁、簇级锁、表级锁和数据库级锁。在如图4所示的结构中，数据行存放在页上，页存放在簇上，一个表有若干个簇组成，而若干个表组成了数据库。在这些可以锁定的资源中，最基本的资源是行、页和表，而簇和数据库是特殊的可以锁定的资源。

图4  表、页、行的结构图

    行是可以锁定的最小空间。在SQL Server 7.0中，实现了行级锁。行级锁就是指事务在操纵数据的过程中，锁定一行或者若干行数据，其他事务不能同时处理这些行的数据。行级锁占用的数据资源最少，所以在事务的处理过程中，允许其他事务继续操纵同一个表或者同一个页的其他数据，大大降低了其他事务等待处理的时间，提高了系统的并发性。页级锁是一种最优锁，因为行级锁不可能出现数据既被占用又没有使用的浪费现象。在图5中，椭圆形表示行级锁占用的数据，而椭圆形之外的其他数据仍然可以由其他事务使用。行级锁是SQL Server 7.0的重要特征，它的引入引起了数据存储引擎的改变。

图5  行级锁

    页级锁是指在事务的操纵过程中，无论事务处理数据的多少，每一次都锁定一页，在这个页上的数据不能被其他事务操纵。在SQL Server 7.0以前，使用的是页级锁。页级锁锁定的资源比行级锁锁定的数据资源多。在页级锁中，即使是一个事务只操纵页上的一行数据，那么该页上的其他数据行也不能被其他事务使用。因此，当使用页级锁时，会出现数据的浪费现象，也就是说，在同一个页上会出现数据被占用却没有使用的现象。在这种现象中，数据的浪费最多不超过一个页上的数据行。在图6中，圆形区表示一个页级锁，在这个圆形区内，只有一个事务可以可以使用圆形区中的数据，其他事务只能使用圆形区以外的数据。

图6  页级锁

    簇级锁是一种特殊类型的锁，只能用在一些特殊的情况下。簇级锁就是指事务占用一个簇，这个簇不能同时被其他事务占用。例如在创建数据库和创建表时，系统分配物理空间时使用这种类型的锁。系统是按照簇分配空间的。当系统分配空间时，使用簇级锁，防止其他事务同时使用同一个簇。当系统完成分配空间之后，就不再使用这种类型的簇级锁。特别是，当涉及到对数据操作的事务时，不使用簇级锁。簇级锁的结构如图7所示。椭圆形区域表示簇级锁占用的数据，其他事务只能使用该簇以外的其他簇。

图7  簇级锁

    表级锁也是一个非常重要的锁。表级锁是指事务在操纵某一个表的数据时，锁定了这个数据所在的整个表，其他事务不能访问该表中的其他数据。当事务处理的数据量比较大时，一般使用表级锁。表级锁的特点是使用比较少的系统资源，但是却占用比较多的数据资源。与行级锁和页级锁相比，表级锁占用的系统资源例如内存比较少，但是占用的数据资源却是最大。在表级锁时，有可能出现数据的大量浪费现象，因为表级锁锁定整个表，那么其他的事务都不能操纵表中的其他数据。这样，会延长其他事务等待处理的时间，降低系统的并发性能。表级锁的结构示意图如图8所示，椭圆形表示表级锁。

图8  表级锁

    数据库级锁是指锁定整个数据库，防止任何用户或者事务对锁定的数据库进行访问。数据库级锁是一种非常特殊的锁，它只是用于数据库的恢复操作过程中。这种等级的锁是一种最高等级的锁，因为它控制整个数据库的操作。只要对数据库进行恢复操作，那么就需要设置数据库为单用户模式，这样系统就能防止其他用户对该数据库进行各种操作。数据库级锁的结构示意图如图9所示。严格地说，数据库级锁不是一种锁，而是一种类似锁的一种单用户模式机制。但是，这种单用户模式机制非常类似锁机制，因此也可以把这种单用户模式称为数据库级锁。

图9  数据库级锁

锁的类型和其兼容性

锁定资源的方式有两种基本形式，一种形式是读操作要求的共享锁，另一种形式是写操作要求的排它锁。除了这两种基本类型的所，还有一些特殊情况的锁，例如意图锁、修改锁和模式锁。在这些各种类型的锁中，有些类型的锁之间是可以兼容的，有些类型的锁之间是不兼容的。

共享锁允许并行事务读取同一种资源，这时的事务不能修改访问的数据。当使用共享锁锁定资源时，不允许修改数据的事务访问数据。当读取数据的事务读完数据之后，立即释放所占用的资源。一般地，当使用SELECT语句访问数据时，系统自动对所访问的数据使用共享锁锁定。对于那些修改数据的事务，例如使用INSERT、UPDATE和DELETE语句，系统自动在所修改的事务上放置排它锁。排它锁就是在同一时间内只允许一个事务访问一种资源，其他事务都不能在有排它锁的资源上访问。在有排它锁的资源上，不能放置共享锁，也就是说不允许可以产生共享锁的事务访问这些资源。只有当产生排它锁的事务结束之后，排它锁锁定的资源才能被其他事务使用。

除了上面的基本锁以外，根据不同的情况，SQL Server还可以使用一些其他类型的锁。这些特殊类型的锁包括意图锁、修改锁和模式锁。

系统使用意图锁来最小化锁之间的冲突。意图锁建立一个锁机制的分层结构，这种结构依据锁定的资源范围从低到高依次是行级锁层、页级锁层和表级锁层。意图锁表示系统希望在层次低的资源上获得共享锁或者排它锁。例如，放置在表级上的意图锁表示一个事务可以在表中的页或者行上放置共享锁。在表级上设置共享锁防止以后另外一个修改该表中页的事务在包含了该页的表上放置排它锁。意图锁可以提高性能，这是因为系统只需要在表级上检查意图锁，确定一个事务能否在哪个表上安全地获取一个锁，而不需要检查表上的每一个行锁或者页锁，确定一个事务是否可以锁定整个表。意图锁有三种类型，即意图共享锁、意图排它锁和使用意图排它的共享锁。意图共享锁表示读低层次资源的事务的意图，把共享锁放在这些单个的资源上。意图排它锁表示修改低层次的事务的意图，把排它锁放在这些单个资源上。意图排它锁包括意图共享锁，它是意图共享锁的超集。使用意图排它的共享锁表示允许并行读取顶层资源的事务的意图，并且修改一些低层次的资源，把意图排它锁放在这些单个资源上。例如，表上的一个使用意图排它的共享锁把共享锁放在表上，允许并行读取，并且把意图排它锁放在将要修改的页上，把排它锁放在修改的行上。每一个表一次只能有一个使用意图排它的共享锁因为表级共享锁阻止对表的任何修改。使用意图排它的共享锁是共享锁和意图排它锁的组合。

当系统将要修改一个页时，使用修改锁。在系统修改该页之前，系统自动地把这个修改页锁上升到排它页锁，防止锁之间发生冲突。当第一次读取页时，在修改操作的开始阶段，获得修改锁。修改锁与共享锁是兼容的。如果该页被修改了，那么修改锁上升到排它锁。

模式锁保证当表或者索引被另外一个会话参考时，不能被删除或者修改其结构模式。SQL Server系统提供了两种类型的模式锁：模式稳定锁和模式修改锁。模式稳定锁确保锁定的资源不能被删除，模式修改锁确保其他会话不能参考正在修改的资源。

有些锁之间是兼容的，例如共享锁和修改锁之间。有些锁之间是不兼容的，例如排它锁和共享锁之间。下面的表1列出了SQL Server系统提供的各种锁之间的兼容性。

表1  SQL Server系统提供的各种锁之间的兼容性

另外，除了表1中列出的锁之间的兼容性之外，对于模式锁来说，模式修改锁对于全部锁都是不兼容的，而模式稳定锁对于除了模式修改锁之外的全部锁都是兼容的。

数据库事务和锁（五）

死锁问题

死锁是一个很重要的话题。在事务和锁的使用过程中，死锁是一个不可避免的现象。在两种情况下，可以发生死锁。第一种情况是，当两个事务分别锁定了两个单独的对象，这时每一个事务都要求在另外一个事务锁定的对象上获得一个锁，因此每一个事务都必须等待另外一个事务释放占有的锁，这时，就发生了死锁。这种死锁是最典型的死锁形式。在同一时间内有两个事务A和B，事务A有两个操作：锁定表part和请求访问表supplier；事务B也有两个操作：锁定表supplier和请求访问表part。结果，事务A和事务B之间发生了死锁，其示意进程如图10所示。

图10   死锁示意图

死锁的第二种情况是，当在一个数据库中时，有若干个长时间运行的事务执行并行的操作，当查询分析器处理一种非常复杂的查询例如连接查询时，那么由于不能控制处理的顺序，有可能发生死锁现象。

当发生死锁现象时，系统可以自动检测到，然后通过自动取消其中一个事务来结束死锁。在发生死锁的两个事务中，根据事务处理时间的长短作为规则来确定他们的优先级。处理时间长的事务具有较高的优先级，处理时间较短的事务具有较低的优先级。在发生冲突时，保留优先级高的事务，取消优先级低的事务。

会话级锁和表级锁

一般地，锁是由系统自动提供的。但是，在有些情况下，用户也可以定制锁。也就是说，用户可以对会话级锁和表级锁进行定制。

会话级锁的定制包括两个方面，事务孤立等级和锁超时限制。事务孤立等级保护指定的事务，该事务孤立等级允许对一个会话中的全部事务设置孤立等级。当设置孤立等级时，就为会话中的全部语句指定了默认的锁定行为。在指定事务孤立等级时，使用到下面一些选项。READ COMMITTED选项指导系统在读取数据时，使用共享锁。在这种选项下，不能体会到脏读，即不能看到正在修改的数据。但是，在事务结束之前，可以改变数据，所以可以产生不可重复读数据或者幻觉数据。READ UNCOMMITTED选项指导系统既不使用共享锁，也不使用排它锁。在这种选项下，可以看到正在修改的数据，体会到脏读。这个选项是限制程度最低的设置。REPEATABLE READ选项指导系统在查询使用的全部数据上放置锁，防止其他用户修改数据，但是幻觉读可以发生。SERIALIZABLE选项指导系统在数据上放置锁，直到事务完成以后，用户才可以修改或者插入数据。这个选项是限制程度最高的设置。另外，事务等待访问的时间也可以定制，这需要设置锁超时限制。当设置了锁超时时间以后，如果事务等待的时间超过了锁超时时间，那么该事务被自动取消。

定制表级锁就是指通过为表指定一个或者多个选项，设置表级锁的行为。实际上，定制表级锁，就是使用一种优化隐藏的方式。优化隐藏就是指在FROM子句后面，附加上有关的内容选项，提高系统识辨操作的能力。定制表级锁有许多选项。ROWLOCK选项指导系统使用行级锁而不是页级锁或者表级锁，这是系统的默认选项。PAGLOCK选项指导系统使用页级锁。TABLOCK选项指导系统使用表级锁而不是使用锁定对象更细的行级锁或者页级锁，并且使用共享锁，因此允许其他事务读取表中的数据，但是不能修改表中的数据。TABLOCKX选项指导系统使用排它锁，防止其他事务读取或者修改表中的任何数据。NOLOCK选项指导系统不使用锁，既不使用共享锁，也不使用排它锁。在这种情况下，可以体会到脏读。HOLDLOCK选项指导系统占有共享锁直到该事务的结束，而不是当有其他锁请求时立即释放。UPDLOCK选项指导事务在读取表中的数据时，使用修改的页级锁代替共享锁。这个锁一直占用到该语句或者事务的结束为止。

结论

    网络技术是信息技术发展的趋势。多用户、多事务、可伸缩、复制、数据仓库等等都是为了适应网络技术的数据库发展方向。事务作为一个重要的数据库技术的基本概念，在保护数据库的可恢复性和多用户、多事务方面具有基础性的作用。一个事务就是一个单元的工作，该事务可能包括一条语句，也可能包括一百条语句，而这些语句的所有操作，要么都完成，要么都取消。在数据库备份和恢复过程中，事务也具有重要作用，可以利用日志进行事务日志备份、增量备份，而不必每一次都执行耗费时间、精力和备份介质的完全备份。锁是实现多用户、多事务等并发处理方式的手段。锁的类型和资源有多种。锁是由系统自动提供的，用户也可以进行一些定制。在SQL Server 7.0中，一个明显的特征是使用了行级锁。使用行级锁引起了数据存储引擎、事务管理方式等方面的变化。