图片 1

In-Memory:内存优化表的事务处理

Snapshot隔离级别使用乐观并发模式,如果一个Snapshot
事务尝试去提交数据行的更新,但是该数据行已经被其他事务修改,并且修改的时间早于当前事务开始的时间,那么SQL
Server将当前事务作为失败者,并回滚其事务操作。乐观并发模式用于冲突较少的环境中,如果Application在更新数据时经常发生冲突,Snapshot隔离级别可能不是最好的选择。

The table has three rows: r1, r2, and r3.
r1 has three versions, r2 has two versions, and r3 has four versions.
Note that different versions of the same row do not necessarily occupy
consecutive memory locations. The different row versions can be
dispersed throughout the table data structure.

隔离级别定义事务处理数据读取操作的隔离程度,在SQL
Server中,隔离级别只会影响读操作申请的共享锁(Shared
Lock),而不会影响写操作申请的互斥锁(Exclusive
Lock),隔离级别控制读操作的行为:

在执行数据更新操作,需要等待事务日志持久化写入到Disk,虽然等待持续的时间通常非常短暂,但是,可以通过以下两个方式来避免:

Specifies that data read by any statement
in a transaction will be the transactionally consistent version of the
data that existed at the start of the transaction. The transaction can
only recognize data modifications that were committed before the start
of the transaction. Data modifications made by other transactions after
the start of the current transaction are not visible to statements
executing in the current transaction. The effect is as if the statements
in a transaction get a snapshot of the committed data as it existed at
the start of the transaction.

悲观策略认为每一个数据更新都潜在地存在冲突,为了避免数据争用,事务在读取数据时申请共享锁,在更新数据时对数据加互斥锁(Locking)。在冲突发生时,通过加锁阻塞其他事务;其他事务检测到冲突后,等待拥有资源的事务释放互斥锁,其他事务只有获取到资源上的加锁,才能执行读写操作。

SET TRANSACTION ISOLATION LEVEL
     READ UNCOMMITTED
    | READ COMMITTED
    | REPEATABLE READ
    | SNAPSHOT
    | SERIALIZABLE

DBCC UserOptions

在Server端执行重试逻辑,仅用于在事务失败时,不向Client返回任何结果集,重试逻辑的示例代码如下:

SET TRANSACTION ISOLATION LEVEL SNAPSHOT
  • Error 41302. The current
    transaction attempted to update a record in table X that has been
    updated since this transaction started. The transaction was
    aborted. When the current transaction attempts to insert a row with
    the same primary key value as a row that was inserted by another
    transaction that committed before the current transaction, there
    will be a failure to commit with the following error message.
  • Error 41325. The current
    transaction failed to commit due to a serializable validation
    failure. If a transaction writes to a table that is dropped before
    the transaction commits, the transaction terminates with the
    following error message:
  • Error 41305. The current
    transaction failed to commit due to a repeatable read validation
    failure.

前提是必须设置数据库选项ALLOW_SNAPSHOT_ISOLATION为ON;一旦启用RCS选项,在默认的Read
Committed
隔离级别中,事务访问版本化的数据行。在RCS隔离级别下,事务有两个特性:

  • 并发事务之间产生冲突,分为更新冲突(Update
    Conflict)和验证失败(Validation Failure):

    • 更新冲突:在同一时刻,有两个并发事务尝试更新同一数据行;错误代码是41302;
      • This error condition occurs
        if two concurrent transactions attempt to update or delete
        the same row at the same time. One of the two transactions
        receives this error message and will need to be
        retried. 
    • 验证失败:验证事务更新是否满足隔离级别Repeatable Read 和
      Serializable的条件,检查数据行是否重复读,检查数据范围是否不变;错误代码是41305,41325;
  • 依赖失败:当前事务依赖其他事务,而依赖的事务提交失败;错误代码是
    41301;

一旦启用Snapshot隔离级别,在事务中执行更新操作时,SQL
Server将被更新的数据行的原始版本存储在tempdb中,即在tempdb中保存数据行的Original
data,因此,读取行版本的数据,都只能读取到数据行被更新之前的值。每一个事务都拥有一个唯一的,递增的顺序号,记作TSN(Transaction
Sequence
Number),TSN能够唯一标识一个事务,每一个行版本都存储一个TSN,标识创建该行版本的事务。

  • 使用Delayed Durability;
  • 创建Non-Durable的MOT,使用SCHEMA_ONLY将完全避免日志写操作,对非持久化表执行的任何更新操作都不会产生任何的日志IO操作;

When the SNAPSHOT isolation level is
enabled, each time a row is updated, the SQL Server Database Engine
stores a copy of the original row in tempdb, and adds a transaction
sequence number to the row. The following is the sequence of events that
occurs:

在In-Memory OLTP系统中,存在两种事务隔离级别,访问硬盘表(Disk-Based
Table,简称DBT)的事务,和访问MOT的事务;和传统的事务隔离级别不同,在一个事务中,存在两个隔离级别。

ALTER DATABASE CURRENT SET SINGLE_USER 
WITH ROLLBACK IMMEDIATE; 
ALTER DATABASE CURRENT SET ALLOW_SNAPSHOT_ISOLATION ON; 
ALTER DATABASE CURRENT SET READ_COMMITTED_SNAPSHOT ON; 
ALTER DATABASE CURRENT SET MULTI_USER;

Phase3:事务提交处理阶段,事务日志记录到日志文件,事务提交完成,一旦日志写入到Disk,控制权返回到客户端

alter database current
set allow_snapshot_isolation on;

alter database current 
set read_committed_snapshot on;

2,如果设置Session的隔离级别为Read Committed:

  • 在 Read
    Uncommitted隔离级别下,读操作不会申请Shared Lock;
  • 在 Read
    Committed(不使用row-versioning),Repeatable Read 和
    Serializable隔离级别下,都会申请Shared Lock;
  • 在 Read
    Committed(不使用row-versioning)
    隔离级别下,在读操作执行时,申请和持有Share
    Lock;一旦读操作完成,释放Shared Lock;
  • 在 Repeatable Read 和
    Serializable隔离级别下,事务会持有Shared
    Lock,直到事务结束(提交或回滚);
  • 在Serializable隔离级别下,事务会持有范围Shared
    Lock(Range
    Lock),锁定一个范围,在事务活跃期间,其他事务不允许在该范围中进行更新(Insert
    或 delete)操作;

懒提交事务持久化使用异步写模式,将事务日志异步地写入到事务日志文件(.ldf)中。在异步写日志模式下,SQL
Server把产生的事务日志先保存在缓存中,直到填满缓存空间,或发生缓存刷新事件,事务日志才被写入到事务日志文件(.ldf)中。懒提交之所以能够减少IO操作的延迟和竞争,是因为有以下三点优势:

行版本是指存储在tempdb中,含有数据行和TSN的数据。数据表的一个Data
Row,可以有多个Row Version。修改操作发生时,SQL Server 创建一个Row
Version,将Original Row复制到Row Version,并将当前事务的TSN也存储在Row
Version中。因此,Row Version存储的是修改之前的数据值。

  • 如果一个事务依赖其他事务,那么将产生提交依赖,必须等待其他事务提交成功,当前事务才能提交;
  • 等待事务日志持久化写入到Disk上的事务日志文件(.ldf)中;
  • 提交依赖等待不能避免,通常持续的时间非常短暂;

2,数据库选项READ_COMMITTED_SNAPSHOT(简称RCS)

Transactions in Memory-Optimized
Tables

  • 如果设置选项READ_COMMITTED_SNAPSHOT为OFF,那么事务在执行读操作时申请共享锁,阻塞其他事务的写操作;
  • 如果设置选项READ_COMMITTED_SNAPSHOT为ON,那么事务在执行读操作时使用Row
    Versioning,不会申请共享锁,不会阻塞其他事务的写操作;

Introduction to Memory-Optimized
Tables

  • 当数据库选项 READ_COMMITTED_SNAPSHOT
    设置为ON,Read Committed隔离级别使用Row Version提供语句级别(Statement-Level)的读一致性;

    • When a transaction runs at the
      read committed isolation level, all statements see a snapshot of
      data as it exists at the start of the statement. 
  • Snapshot隔离级别使用Row Version
    提供事务级别(Transaction-Level)的读一致性。在当前事务开始时,任何读操作,都基于相同的数据库snapshot。当读取被其他事务修改的数据行时,从tempdb中获取行版本数据。使用Snapshot隔离级别时,必须设置数据库选项ALLOW_SNAPSHOT_ISOLATION为ON;

    • When reading rows modified by
      another transaction, they retrieve the version of the row that
      existed when the transaction started.
  • 在snapshot 和 read committed
    snpshot隔离级别下,事务读取的数据都是已提交的;
  • 注意语句级别的读一致性和事务级别的读一致性是snapshot
    和 read committed snpshot 最大的区别:

    • 事务级别的读一致性是指:在事务开始,到事务提交期间,该事务持有数据的一个快照。如果在该事务活动期间,其他事务更新表数据,该事务只会读取快照数据,不会读取到被其他事务更新的数据值;
    • 语句级别的读一致性是指:单个语句(single
      statement)看到的数据是一致性的;在当前事务活动期间,事务中的语句能够读取到被其他事务提交更新的数据值;例如,在语句stmt1执行时,事务没有提交更新,stmt1看到Reader1的值是2;当语句stmt2执行时,事务提交更新,stmt2看到Reader2的值是3;

参考文档:

  • 如果设置RCS选项为OFF(默认设置),数据库引擎使用Shared
    Lock阻止其他事务修改当前事务正在读取的数据;当读取被其他事务修改,但尚未提交更新的数据行时,该读操作将被阻塞;

    • If READ_COMMITTED_SNAPSHOT is
      set to OFF (the default), the Database Engine uses shared locks
      to prevent other transactions from modifying rows while the
      current transaction is running a read operation. The shared
      locks also block the statement from reading rows modified by
      other transactions until the other transaction is completed.
  • 如果设置RCS选项为ON,数据库引擎使用行版本化(Row
    Versioning)的数据实现语句级别的一致性,不会阻塞其他事务的写操作,但只能读取已提交更新的数据

    • If READ_COMMITTED_SNAPSHOT is
      set to ON, the Database Engine uses row versioning to present
      each statement with a transactionally consistent snapshot of the
      data as it existed at the start of the statement. Locks are not
      used to protect the data from updates by other
      transactions.

1, 如果设置Session的隔离级别为Read
Uncommitted,事务访问MOT,将产生错误,MOT不支持Read
Uncommitted隔离级别

2,使用Read_Committed_Snapshot隔离级别

 

在使用Snapshot隔离级别时,必须将当前Session的隔离级别设置为Snapshot,只有这样,当前事务才能访问Row
Versioning的数据:

如果发生MSSQLSERVER_41333
错误,说明产生交叉事务隔离错误(CROSS_CONTAINER_ISOLATION_FAILURE),原因是当前事务的隔离级别太高,解决方法是:将Session-Level的事务隔离级别降低到Read
Committed。

当启用Snapshot隔离级别时,每一个更新数据的操作都会在tempdb中存储该行的原始副本,术语叫作行版本(RowVersion),SQL
Server为每个行版本添加事务的TSN,该TSN能够唯一标识更新操作所在的事务。读操作在读数据时,按照以下顺序进行:

MOT的同一行数据可以有不同的版本,因此,并发执行事务可能访问同一行数据的不同版本,由于在同一时刻,任何数据行都有可能拥有不同行版本,并且都是有效的;如果根据数据行的不同版本执行数据更新操作,有可能产生逻辑错误。MOT维护的多行版本(Row-Version)不是存储在tempdb中,而是直接存储在MOT中,作为MOT数据结构的一部分存储在内存中。

参考文档:

三,访问MOT的事务隔离级别

3,Snapshot 使用乐观并发模式

乐观策略认为执行的数据更新操作很少存在冲突,事务在读取数据时,不锁定数据;在更新数据时,事务只在提交时检查更新的有效性,如果有其他事务更新该数据,将产生更新冲突的错误,那么事务不等待,SQL
Server选择一个事务作为失败者,并回滚事务执行的操作。乐观策略效率更高,部分原因是在大多数情况下,更新冲突不经常发生。当冲突发生时,使用悲观策略,事务需要等待;使用乐观策略,SQL
Server使事务失败,回滚事务操作。

Isolation Levels in the Database
Engine.aspx)

CREATE PROCEDURE <procedureName> …    
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER    
AS BEGIN ATOMIC WITH     
(    
    DELAYED_DURABILITY = ON,    
    TRANSACTION ISOLATION LEVEL = SNAPSHOT,    
    LANGUAGE = N'English' …    
)    
END
set transaction isolation level snapshot
-- Retry logic, in Transact-SQL.  
CREATE PROCEDURE usp_update_salesorder_dates  
AS  
BEGIN  
    DECLARE @retry INT = 10;  

    WHILE (@retry > 0)  
    BEGIN  
        BEGIN TRY  
            BEGIN TRANSACTION;  

            UPDATE dbo.SalesOrder_mo WITH (SNAPSHOT)  
                set OrderDate = GetUtcDate()  
                where CustomerId = 42;  

            UPDATE dbo.SalesOrder_mo WITH (SNAPSHOT)  
                set OrderDate = GetUtcDate()  
                where CustomerId = 43;  

            COMMIT TRANSACTION;  
            SET @retry = 0;  -- //Stops the loop.  
        END TRY  

        BEGIN CATCH  
            SET @retry -= 1;  

            IF (@retry > 0 AND ERROR_NUMBER() in (41302, 41305, 41325, 41301, 41839, 1205)  )  
            BEGIN  
                IF XACT_STATE() = -1  
                    ROLLBACK TRANSACTION;  

                WAITFOR DELAY '00:00:00.001';  
            END  
            ELSE  
            BEGIN  
                print 'Suffered an error for which Retry is inappropriate.';  
                THROW;  
            END  
        END CATCH  

    END -- //While loop  
END; 

The net effect of snapshot isolation is
that the transaction sees all of the data as it existed at the start of
the transaction, without holding or placing any locks on the underlying
tables. This can result in performance improvements in situations where
there is contention.

1,并发控制策略

A snapshot transaction always uses
optimistic concurrency control, with holding any locks that would
prevent other transactions from updating rows. If a snapshot transaction
attempts to commit an update to a row that was changed after the
transaction began, the transaction is rolled back, and an error is
raised.

乐观策略主要用于数据争用不大,并且偶尔回滚事务的成本低于读取数据时锁定数据的成本的环境中。

 图片 1

1,将数据库设置为懒提交模式

read committed snapshot隔离级别,读取行版本化的已提交数据:

View Code

在默认的隔离级别Read Commited下,在执行读操作时,事务申请shared
lock,读写操作相互阻塞。在隔离级别Read Uncommitted下,事务不会申请shared
lock,因此读操作不会阻塞写操作,但是读操作可能会读到脏数据。脏数据是指被其它尚未提交的事务修改之后的数据值,不是指更新之前的数据值。

3,在Commit子句中,指定懒提交选项

在任何隔离级别下,事务在执行写操作时都申请互斥锁(exclusive
lock),持有互斥锁直到事务结束,互斥锁不受隔离级别的控制;而共享锁(Shared
Lock)受到隔离级别的控制,隔离级别影响Shared Lock的申请和释放:

在显式事务(Explicit)模式中,如果默认的事务隔离级别低于SNAPSHOT,那么必须提升事务隔离级别,才能访问MOT,有两种实现方式: 

在默认的隔离级别Read Committed下,使事务能够访问Row
Versioning数据,需要将数据库选项READ_COMMITTED_SNAPSHOT设置为ON:

3,如果设置Session的隔离级别为Snapshot,无法访问MOT

3,READ COMMITTED Snapshot隔离级别

2,在Natively Compiled SP中,将Atomic Block设置为懒提交

  • A new transaction is initiated, and
    it is assigned a transaction sequence number.

  • The Database Engine reads a row
    within the transaction and retrieves the row version
    from tempdb whose sequence number is closest to, and lower than,
    the transaction sequence number.

  • The Database Engine checks to see if
    the transaction sequence number is not in the list of transaction
    sequence numbers of the uncommitted transactions active when the
    snapshot transaction started.

  • The transaction reads the version of
    the row from tempdb that was current as of the start of the
    transaction. It will not see new rows inserted after the transaction
    was started because those sequence number values will be higher than
    the value of the transaction sequence number.

  • The current transaction will see rows
    that were deleted after the transaction began, because there will be
    a row version in tempdb with a lower sequence number
    value.

在SQL Server中,事务提交可以是完全持久化的(Full
Durable,默认),也可以是延迟持久化的(Delayed Durable),也叫做Lazy
Commit。

Snapshot隔离级别实现事务级别的数据一致性,这意味着,在单个事务中的所有查询语句,看到的是相同版本的数据。在Snapshot隔离级别下,事务在读取数据不需要加行级锁或页级锁,读写操作互不阻塞。

在显式事务中,访问MOT,将产生错误:

Choosing a transaction isolation level
does not affect the locks acquired to protect data modifications. A
transaction always gets an exclusive lock on any data it modifies, and
holds that lock until the transaction completes, regardless of the
isolation level set for that transaction. 

对硬盘表(Disk-Based
Table,简称DBT),Snapshot隔离级别将行版本化的数据存储在tempdb中;在其他隔离级别(例如,Read
Committed,Repeatable,Serializable)下,事务通过加锁避免冲突。对于MOT,事务不会加锁,MOT使用多行版本实现事务的并发控制,和Disk-Based
Table不同的是,MOT的版本化数据存储在MOT的内存数据结构中,而不是存储在tempdb中。MOT的每一个数据行在内存中可能存在多个版本,每一个版本都保存在相同的数据结构中。实际上,MOT的数据结构是Row
Version的集合,相同Row的不同Version不需要存储在连续的内存地址中,每一个Row
Version是分散地存储在MOT中,每一个Row Version使用8B的内存地址来寻址。

二,使用行版本(Row Version)的隔离级别

1,交叉事务(cross-container transaction)

1,使用snapshot 隔离级别

3,等待(Waiting)

2,Snapshot隔离实现事务一致性

2,访问MOT的事务生命周期

snapshot隔离级别不会阻塞其他事务的写操作,该隔离级别忽略数据的修改操作,只读取row
versioning的数据,就是说,读取到的是数据修改之前的版本,当snapshot事务尝试修改由其他事务修改的数据时,产生更新冲突,写操作异常终止。

SQL Server 支持四种事务初始化模式:

SQL Server 数据库级别默认的事务隔离级别是Read
Committed,用户不能修改Database-Level默认的隔离级别,但是,用户能够修改Session-Level默认的事务隔离级别。Session-Level默认的事务隔离级别是Read
Committed,该隔离级别受到数据库选项 READ_COMMITTED_SNAPSHOT 的影响,决定Read
Committed隔离级别是使用行版本控制事务的读操作,还是使用加共享锁来控制事务的读操作,在默认的Read
Committed隔离级别下:

2,使用行版本实现Snapshot事务隔离

SQL Server支持使用Row Version的隔离级别,事务的读操作只申请SCH-S 表级锁,不会申请Page
锁和Row 锁,事务的修改操作仍然申请锁

悲观策略主要用于数据争用激烈,并且发生发冲突时用锁保护数据的成本低于回滚事务的成本的环境中。

Once snapshot isolation is enabled,
updated row versions for each transaction are maintained in tempdb.
A unique transaction sequence number identifies each transaction, and
these unique numbers are recorded for each row version.

ALTER DATABASE DatabaseName
SET DELAYED_DURABILITY = { DISABLED | ALLOWED | FORCED }  

step1,设置数据库选项

一,MOT使用乐观并发事务控制

  • 创建一个新的事务,为其分配TSN,一个唯一,递增的序号;
  • snapshot事务从数据表中读取数据行,从tempdb中读取行版本(row
    version),该行版本的TSN最接近当前事务的TSN,但比当前事务的TSN小;
  • 在创建Snapshot时,从已提交的事务中获取行版本数据,如果行版本数据标识的事务尚未提交,那么从更早的事务中获取已提交更新的数据;
  • 事务从tempdb中读取行版本数据,事务不会看到新插入的数据,因为插入数据的TSN比当前事务的TSN大;
  • 事务能够看到被其他事务删除的数据,前提是删除数据的事务的TSN比当前事务的TSN大,这是因为其他事务将行版本保存到tempdb中,当前事务从tempdb中读取行版本数据;
COMMIT [ { TRAN | TRANSACTION } ] [ transaction_name ] ] [ WITH ( DELAYED_DURABILITY = { OFF | ON } ) ] 

4,Snapshot 隔离和 Row Version的工作模式

在SQL Server
2016中,有两种方式指定隔离级别:当在解释性TSQL中访问MOT时,使用Table
Hint指定SNAPSHOT隔离级别;当在Natively Compiled
存储过程中访问MOT时,必须在Atomic Block中指定隔离级别为SNAPSHOT。

事务的隔离级别共有5个,使用SET命令修改Session-Level的隔离级别,使用DBCC
UserOptions 查看当前Session的隔离级别:

交叉事务是指在一个事务中,解释性TSQL语句同时访问MOT和DBT。在交叉事务中,访问MOT的操作和访问DBT(Disk-Based
Table)的操作都拥有自己独立的事务序号,就像在一个大的交叉事务下,存在两个单独的子事务,分别用于访问MOT和DBT;在sys.dm_db_xtp_transactions
(Transact-SQL)中,访问DBT的事务使用transaction_id标识,访问MOT的事务序号使用xtp_transaction_id标识。

1,在Snapshot隔离级别下,更新操作创建Row Version

2,提升事务的隔离级别

 

乐观估计效率更高,部分原因是在大多数情况下,事务冲突不经常发生。当冲突发生时,使用悲观估计法,事务需要等待;使用乐观估计法,SQL
Server使事务失败,并回滚事务操作,因此,在发生更新冲突时,需要在客户端进行异常检测,重新执行事务。

  • 在读数据时是否使用共享锁,申请何种类型的锁;
  • 事务持有读锁的时间;
  • 读操作引用被其他事务更新,但尚未提交的数据行时,控制读操作的行为:
    • 被阻塞,等待其他事务释放互斥锁;
    • 获取更新之前的数据值,从tempdb中读取行版本,该行版本在事务开始时已经提交;Retrieves
      the committed version of the row that existed at the time the
      statement or transaction started.
    • 读没有提交的数据,获取更新之后的数据值;

实际上,访问MOT,事务必须处在SNAPSHOT隔离级别下,SNAPSHOT隔离级别指定在读操作执行时,数据在事务级别保持一致性,这意味着,在一个事务中的任何读操作,读取的数据是事务一致性的数据版本。事务一致性是指在事务开始时,创建数据快照:在事务开始时,已经提交的事务更新,能够被该事务识别;在事务开始之后,被其他事务提交的数据更新操作,不会被当前事务识别。

一,事务的隔离级别

事务的并发控制策略分为乐观策略和悲观策略,SQL Server支持两种并发策略。

三,启用快照隔离级别

  • 在该阶段,有时会产生更新冲突(Update
    Conflict),如果当前事务更新的数据行,被其他事务更新,但未提交,那么会产生更新冲突;

    • If any query tries to update a
      row that has already been updated by an active transaction, an
      ‘update conflict’ error is generated.
  • 在该阶段,有时会产提交依赖(Commit
    Dependence),这是因为事务读取到被其他事务更新,但是尚未提交(处于验证或提交阶段);

    • 依赖失败(Dependency
      failure):如果当前事务依赖的事务提交失败,那么当前事务失败,产生错误
      41301;
  • During regular processing, a
    transaction can read rows written by other transactions that are in
    the validation or commit phase, but have not yet committed. The rows
    are visible because the logical end time of the transactions has
    been assigned at the start of the validation phase.

四,引用徐海蔚老师的例子,测试隔离级别的行为

Accessing memory
optimized tables using the READ COMMITTED isolation level is supported
only for autocommit transactions. It is not supported for explicit or
implicit transactions. Provide a supported isolation level for the
memory optimized table using a table hint, such as WITH
(SNAPSHOT).

图片 2图片 3

alter database current set allow_snapshot_isolation on
set transaction isolation level snapshot

在SNAPSHOT隔离级别下,任何写操作都会将更新之前的数据行保存到tempdb中,读取操作要么从Original
Database的数据表中读取数据,要么从tempdb中读取行版本数据。Snapshot隔离级别指定:在一个事务中,任何语句读取的数据,是事务一致性的版本。事务一致性是指在事务开始时,在表级别创建数据快照,只能识别其他事务已提交的数据更新。在事务开始之后,当前事务不会识别其他事务执行的数据更新。Sanpshot隔离级别实现事务级别的数据一致性。SQL
Server 使用tempdb来存储行版本化(row
versioning)的数据,如果数据更新较多,存储的行版本太多,会导致tempdb成为系统瓶颈。

  • 事务提交不需要等待写日志操作的完成,一旦查询语句执行完成,就把控制权返回给Client,提高了数据更新的响应速度;
  • 减少并发的事务产生写日志竞争的可能性;
  • 在懒提交模式下,日志被缓存起来,系统一次能够将更大块的日志记录写入到Disk,减少了Disk
    IO竞争,提高了数据更新的性能;