隔离级别,三级封锁协议,脏读,丢失更新,不可重复读和虚读

 

脏读,丢失更新,不可重复读和虚读,三级封锁协议: http://hi.baidu.com/kingbridge/blog/item/0f1c244e573c36ccd1c86a24.html有很详细的例子和说明。

PS:1.脏读,丢失更新,不可重复读和虚读都是针对同一事物中同一动作的多次执行的不同结果的前提。

         2.三级封锁协议并不能阻止幻读,修改的不能再被读取,但是新增(删除)的记录数可以统计。

————————————————————————————————

隔离级别:

READ UNCOMMITTED(一级封锁协议)

允许脏读取,但不允许更新丢失。
In the READ UNCOMMITTED isolation level, transactions can view the results of
uncommitted transactions. At this level, many problems can occur unless you
really, really know what you are doing and have a good reason for doing it. This
level is rarely used in practice, because its performance isn’t much better than
the other levels, which have many advantages. Reading uncommitted data is also
known as a dirty read.
READ COMMITTED(二级封锁协议)
The default isolation level for most database systems (but not MySQL!) is READ
COMMITTED. It satisfies the simple definition of isolation used earlier: a transaction
will see only those changes made by transactions that were already committed
when it began, and its changes won’t be visible to others until it has committed.
This level still allows what’s known as a nonrepeatable read. This means you can
run the same statement twice and see different data.

REPEATABLE READ(三级封锁协议)
REPEATABLE READ solves the problems that READ UNCOMMITTED allows. It guarantees
that any rows a transaction reads will “look the same” in subsequent reads
within the same transaction, but in theory it still allows another tricky problem:
phantom reads. Simply put, a phantom read can happen when you select some
range of rows, another transaction inserts a new row into the range, and then
you select the same range again; you will then see the new “phantom” row.
InnoDB and Falcon solve the phantom read problem with multiversion concurrency
control
, which we explain later in this chapter.
REPEATABLE READ is MySQL’s default transaction isolation level. The InnoDB and
Falcon storage engines respect this setting, which you’ll learn how to change in
Chapter 6. Some other storage engines do too, but the choice is up to the engine.

锁机制能解决不可重复读,因为锁定的是当前的行,但是对于幻读这种范围的查询如果有并发插入(next-key lock不生效因为这里是select不是select for update),mvcc提供的一致性快照才能解决。

SERIALIZABLE

提供严格的事务隔离。它要求事务序列化执行,事务只能一个接着一个地执行,但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的,必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。
The highest level of isolation, SERIALIZABLE, solves the phantom read problem by
forcing transactions to be ordered so that they can’t possibly conflict. In a nutshell,
SERIALIZABLE places a lock on every row it reads. At this level, a lot of timeouts
and lock contention may occur. We’ve rarely seen people use this isolation
level, but your application’s needs may force you to accept the decreased concurrency
in favor of the data stability that results.

                                                                                               ———————High.Performance.MySQL_Second.Edition

标签: , , , , ,

留下回复