MySQL transactions and implement, and optimize the isolation level and lock

Affairs     

       A transaction is a series of strict application of the operation, all operations must be completed successfully, otherwise made in each operation, all changes are undone. A transaction is a logical set of operations, or are executed or not executed.

 

ACID Introduction

   Atomicity (Atomicity), consistency (Correspondence), isolation (Isolation), persistent (Durability).

(1) atomicity : all operations throughout the transaction, either completed or not completed all impossible stuck in the middle of a link. Transaction error occurs during execution, it will be rolled back (Rollback) to the state before the start of the transaction, as the transaction never performed the same.
      (2) Consistency : before the transaction begins and after the end of the transaction, integrity constraints of the database is not corrupted.
      (3) Isolation : isolation transaction execution, so that if they were the only operating system executing within a given time. If there are two transactions running at the same time, perform the same function, isolation transaction will ensure that each transaction in the system that only the transaction using the system. This property is sometimes referred to as serialization, in order to prevent confusion between the transaction operations, or be serialized serialized request, so that only one request at the same time for the same data.
      (4) Persistence : After the transaction is completed, the firm changes made to the database will be stored in the persistent database, and will not be rolled back.

ACID FAQ

One problem: Mysql how to ensure consistency?      

 这个问题分为两个层面来说。


  从数据库层面,数据库通过原子性、隔离性、持久性来保证一致性。也就是说ACID四大特性之中,C(一致性)是目的,A(原子性)、I(隔离性)、D(持久性)是手段,是为了保证一致性,数据库提供的手段。数据库必须要实现AID三大特性,才有可能实现一致性。例如,原子性无法保证,显然一致性也无法保证。但是,如果你在事务里故意写出违反约束的代码,一致性还是无法保证的。例如,你在转账的例子中,你的代码里故意不给B账户加钱,那一致性还是无法保证。因此,还必须从应用层角度考虑。


  从应用层面,通过代码判断数据库数据是否有效,然后决定回滚还是提交数据!

Second problem: Mysql how to ensure atomicity?  

利用Innodb的undo log。
  undo log名为回滚日志,是实现原子性的关键,当事务回滚时能够撤销所有已经成功执行的sql语句,他需要记录你要回滚的相应日志信息。
例如

(1)当你delete一条数据的时候,就需要记录这条数据的信息,回滚的时候,insert这条旧数据

(2)当你update一条数据的时候,就需要记录之前的旧值,回滚的时候,根据旧值执行update操作

(3)当年insert一条数据的时候,就需要这条记录的主键,回滚的时候,根据主键执行delete操作

undo log记录了这些回滚需要的信息,当事务执行失败或调用了rollback,导致事务需要回滚,便可以利用undo log中的信息将数据回滚到修改之前的样子。

Question three: Mysql how to ensure durability?  

利用Innodb的redo log。
  正如之前说的,Mysql是先把磁盘上的数据加载到内存中,在内存中对数据进行修改,再刷回磁盘上。如果此时突然宕机,内存中的数据就会丢失。


  怎么解决这个问题?
    简单啊,事务提交前直接把数据写入磁盘就行啊。


  这么做有什么问题?

只修改一个页面里的一个字节,就要将整个页面刷入磁盘,太浪费资源了。毕竟一个页面16kb大小,你只改其中一点点东西,就要将16kb的内容刷入磁盘,听着也不合理。

毕竟一个事务里的SQL可能牵涉到多个数据页的修改,而这些数据页可能不是相邻的,也就是属于随机IO。显然操作随机IO,速度会比较慢。

  于是,决定采用redo log解决上面的问题。当做数据修改的时候,不仅在内存中操作,还会在redo log中记录这次操作。当事务提交的时候,会将redo log日志进行刷盘(redo log一部分在内存中,一部分在磁盘上)。当数据库宕机重启的时候,会将redo log中的内容恢复到数据库中,再根据undo log和binlog内容决定回滚数据还是提交数据。

  采用redo log的好处?
  其实好处就是将redo log进行刷盘比对数据页刷盘效率高,具体表现如下

redo log体积小,毕竟只记录了哪一页修改了啥,因此体积小,刷盘快。

redo log是一直往末尾进行追加,属于顺序IO。效率显然比随机IO来的快。

Question four: Mysql how to ensure the isolation of?

  Use is MVCC locks and mechanisms. Or take the example to illustrate the transfer, there is an account table follows
  the table namet_balance

Where id is the primary key, user_id as the account name, balance is the balance. Or in two transfers, for example, as shown in FIG.

As MVCC, i.e. multi-version concurrency control (Multi Version Concurrency Control), a plurality of data rows snapshot data versions, the snapshot data in undo logthe.

  If the line is doing a transaction reads DELELE or UPDATE operation, the read operation will not wait for the release of the lock on the line, but read the snapshot version of the row.
  Because of MVCC mechanism repeatable read (Repeateable Read) and Read Committed (Read Commited) of MVCC in different forms, not go into details.
  But one thing to explain, for the Read Committed transaction isolation level (Read Commited), a transaction can read data from another transaction has been submitted, the isolation is not satisfied. However, when the transaction isolation level is repeatable read (Repeateable Read), the barrier properties are satisfied.

Published 72 original articles · won praise 7 · views 10000 +

Guess you like

Origin blog.csdn.net/qq_39399966/article/details/104997297