MySql MVCC Multi Version Concurrency Control

background

• MySql Most transactional storage engines do not actually realize a simple row-level locking. Based on lifting consider concurrent performance, they generally have achieved multi-version concurrency control (MVCC).
• MVCC is considered a variant of row-level locking, but it avoids the locking operation, in many cases, and therefore lower costs. Although the implementation mechanism is different, but most achieve non-blocking read operation, write operation is only necessary to lock a row.
• There are many MVCC implementation, typically optimistic concurrency and pessimistic concurrency control.
• MVCC only in READ COMMITTED read committed and REPEATABLE READ Repeatable Read isolation level work under two. The other two are not compatible with the isolation level and MVCC, because READ UNCOMMITED read uncommitted always read the latest data line, rather than in line with the current transaction version of the row. The row lock SERIALIZABLE serialization will all read.

to sum up

1. MVCC is in MySql 事务型存储引擎 InnoDBsupported.
2. Cope with high concurrent transactions, MVCC is more effective than simply adding row lock, with less overhead.
3. MVCC only READ COMMITand REPEATABLE READwork under two isolation levels.
4. MVCC can be accomplished using optimistic and pessimistic.

analysis

1. InnoDB storage engine in the back row of data is not added to the database three fields.

   • 6-byte transaction ID (DB_TRX_ID) fields: the latest update of this mark rows of transaction id, each handling a transaction, automatically value +1.
   • 7 bytes rollback pointer (DB_ROLL_PTR) field: rollback segment directed current record undo log (undo log record), to find the previous version of the data is through this pointer.
   • 6 bytes DB_ROW_ID fields: When a clustered index is generated automatically by InnoDB, including clustered index value DB_ROW_ID otherwise clustered index is not included in this value, for the index.

2. Let's show you the update process transactions on-line records.

   !

3. read view

   In innodb, each create a new thing, the storage engine will create a copy of the list of transactions currently active in the system ( read view), save a copy of the transaction id is a list of other current systems should not be seen in this transaction.

   When a user in a transaction to read a row of record time, the current version of the line will innodb good compared with the read view, the comparison by comparison algorithm.

Comparison algorithm

Assuming that the line of the current transaction id is trx_id_current, read_view in the bank's first transaction id is trx_id_first, the latest transaction id is tax_id_last.

1. If trx_id_current <trx_id_first, it means

   When reading the current transaction the bank records, the transaction ID to be smaller than the other. That means that all current and matters relating to the bank records, the current transaction is the first reading to the bank records, and no changes were made but have not yet submitted data in the row in front of the current transaction transaction Therefore the current transaction can take it directly to the table stable data!

2. If trx_id_current> tax_id_last, it means

   When reading the current transaction the bank records, the transaction ID is bigger than the other read_view the transaction ID. That means that all current and records relating to the bank's affairs, current affairs is the last line read into the record. According DB_ROLL_PTR need a pointer to the rows of pointed out rollback segments in the latest undo-log version number, and then continue the iteration continues, layers down in the undo-log to find, will eventually find stable data!

3. trx_id_first < trx_id_current < tax_id_last，同上。

对比READ COMMITED和REPEATABLE READ

READ COMMITED 读已提交，只能解决脏读问题，但是不能解决不可重复读问题，所以每次都能读取到最新一份数据快照。

REPEATABLE READ可重复读，解决了脏读和不可重复读的问题，所以能读到事务开始前时的数据版本。

• 使得 READ COMMITED 级别能够保证, 只要是当前语句执行前已经提交的数据都是可见的。
• 使得 REPEATABLE READ 级别能够保证, 只要是当前事务执行前已经提交的数据都是可见的。

总结

1. 一般我们认为MVCC有下面几个特点：
   • 每行数据都存在一个版本，每次数据更新时都更新该版本
   • 修改时Copy出当前版本, 然后随意修改，各个事务之间无干扰
   • 保存时比较版本号，如果成功(commit)，则覆盖原记录, 失败则放弃copy(rollback)
   • 就是每行都有版本号，保存时根据版本号决定是否成功，听起来含有乐观锁的味道, 因为这看起来正是，在提交的时候才能知道到底能否提交成功
2. 而InnoDB实现MVCC的方式是:
   • 事务以排他锁的形式修改原始数据
   • 把修改前的数据存放于undo log，通过回滚指针与主数据关联
   • 修改成功（commit）啥都不做，失败则恢复undo log中的数据（rollback）
3. 二者本质的区别是 InnoDB 使用了 拍他锁。
   • InnoDB 的实现算不上 MVCC，因为没有实现核心的多版本共存，undo log 中的内容只是串行化的结果，记录了多个事务的过程，不属于多版本共存。
   • 因为InnoDB使用的MVCC中结合了排他锁, 不是纯的MVCC, 所以第一类更新丢失是不会出现了, 一般说更新丢失都是指第二类丢失更新。