一:MySQL

二:MySQL事务

三:MySQL隔离级别

四:MVCC


1.1为什么要有锁?

    因为数据库要解决并发控制问题。在同一时刻,可能会有多个客户端对某张表的某条数据或某些数据进行操作,比如有的在读取该行数据,其他的尝试去删除它。为了保证数据的一致性,数据库就要对这种并发操作进行控制,因此就有了锁的概念。



1.2锁的分类

    1.2.1按对数据的操作类型

        LOCK TABLES tb_namelock_type{READ|WRITE};

        UNLOCKTABLES ;

        读锁(共享锁):针对同一块数据,多个读操作可以同时进行而不会互相影响。

                        写锁(排它锁):当前写操作没有完成前,它会阻断其他写锁和读锁。

   

        示例1:读锁

            wKiom1VC9CbSzxVtAAA6ZGUdQtI504.jpg

            wKioL1VC9ZDQKiT7AADDPCge_zM471.jpg

            wKiom1VC9Cejjw61AAA4KgRzG_s633.jpg

            wKioL1VC9ZGjtIayAAA6iT3Ep0I751.jpg




        示例2:写锁

              wKioL1VC7qeCaRh_AAA6KslPDO8516.jpg

              wKiom1VC7T7zcO48AABS8KsLa8U833.jpg

              wKioL1VC7qjQQTZhAABBqh-35tg792.jpg

              wKiom1VC7T_AGMk4AACPWT0b1II094.jpg



    

    1.2.2锁的粒度:MySQL服务器仅支持表级别的所,行所需要存储引擎完成

        表锁:管理锁的开销最小,同时允许的并发量也最小的锁机制。MyIsam存储引擎使用的锁机制。当要写入数据时,把整个表都锁上,此时其他读、写动作一律等待。在MySql中,除了MyIsam存储引擎使用这种锁策略外,MySql本身也使用表锁来执行某些特定动作,比如alter table.

 

        行锁:可以支持最大并发的锁策略。InnoDB存储引擎采用这种策略



2.1 ACID

    原子性(Autmic):事务所引起的数据库操作,要么都完成,要么都不执行

        

    一致性(Consistency):完成之前和完成之后是一样的(两个帐户的钱,转账之前和之后的总和是一样的)

        

    隔离性(Isolation):一个事务的执行不能影响另一个事务的执行

        

    持久性(Durability):一旦事务成功完成,系统必须保证任何故障都不能引起事务的不一致性。



2.2事务的状态

    wKioL1VC73HwsrA7AABnbwOC0Nk655.jpg




2.3保存点(SAVEPOINT

    一个很大的事务,这个事务有100个操作,执行到80个的时候发现第75个错了,怎么办?

    撤销??---->80个都撤销了--->不好

        

    这样就引出保存点了,每10个做一次保存点

 

    回滚保存点:ROLLBACK TO sid

    wKiom1VC7mnAA8ulAAC7hysEWlQ662.jpg



    示例:

    wKioL1VC7_Lj5ZSXAAGBV-cqaOk745.jpg

    wKiom1VC7onwZ5aTAAEdlwyOyB8628.jpg




3.1事务的隔离级别

    READ-UNCOMMITTED读未提交  别人一操作,立马就能看见(最低的隔离级别)

                  

    READ-COMMITTED读提交  别人提交了,才能看见

                  

    REPEATABLE-READ可重读 

        (不管别的事务是否提交,我的事务之内看到的依然是一样的,例如A事务执行了UPDATE操    

            作,B事务执行SELECT操作,在A执行前和后,B执行的结果都一样)

                  

    SERIALIZABLE可串行化

        

    查看当前数据库的隔离级别:

        SHOW GLOBAL VARIABLES LIKE '%ISO%';

        SELECT @@TX_ISOLATION;

    wKiom1VC71iyUJXCAADDSWomHqI791.jpg

    wKioL1VC8MOj8aOLAACxQZSftrQ310.jpg




3.2事务隔离级别对事务的影响

3.2.1READ-UNCOMMITTED示例

【客户端1

wKioL1VC8TWiPvY0AAD0sUUuyJs807.jpg


【客户端2

wKioL1VC8TbQSlh1AAD0pZ1I9Pg747.jpg


【客户端1

wKiom1VC782j1ilpAABbaZUxh-4108.jpg


【客户端2

wKioL1VC8TeAks-kAAC_aeRDYWk151.jpg


总结:客户端2在一个事务内,两次读取的数据不一样,产生了幻读



3.2.2READ-COMMITTED

【客户端1

wKiom1VC8FGAX6NQAAEHDELqyaI109.jpg


【客户端2

wKioL1VC8byCR9_CAADpXbcpHcQ182.jpg


【客户端1

wKiom1VC8FLQiiVzAABjI-fqTEU899.jpg


【客户端2

wKioL1VC8byyc3tFAAC5K_R6pps625.jpg


总结:客户端1未执行提交之前,客户端2看不到更新后的数据,客户端1执行提交之后,客户端2看到了更新以后的数据,客户端2在一个事务内,执行两次查询仍然看到了不同的结果,依然存在幻读的问题



3.2.3REPEATABLE-READ

【客户端1

wKioL1VC8jrAwMHIAADztu4tHZo856.jpg


【客户端2

wKiom1VC8NHDz1hbAAFVJz4nLCY905.jpg


【客户端1

wKioL1VC8jvxWBNHAABgf3i-FHM378.jpg


【客户端2

wKiom1VC8NKyFguaAADpcFW-jdk190.jpg

wKioL1VC8jyQhLR2AAC8JOvIWKk550.jpg


总结:客户端2在提交前和提交后看到的数据依然不一样,产生了幻读



3.2.4SERIALIZABLE

【客户端1

wKiom1VC8VbRARFdAADyOKN1dpc115.jpg


【客户端2

wKioL1VC8sDDlkdFAABbgzzpGs8240.jpg


【客户端1

wKiom1VC8VbwpyY0AABBT2POcqw740.jpg


【客户端2

wKiom1VC8VeSf3bQAACX2dqcDd0170.jpg


总结:虽然不存在数据幻读的问题,但是执行效率非常低





以下内容来自于:http://blog.csdn.net/chen77716/article/details/6742128



4.1相关概念


redo log

redo log就是保存执行的SQL语句到一个指定的Log文件,当Mysql执行recovery时重新执行redo log记录的SQL操作即可。当客户端执行每条SQL(更新语句)时,redo log会被首先写入log buffer;当客户端执行COMMIT命令时,log buffer中的内容会被视情况刷新到磁盘。redo log在磁盘上作为一个独立的文件存在,即Innodb的log文件。


undo log

与redo log相反,undo log是为回滚而用,具体内容就是copy事务前的数据库内容(行)到undo buffer,在适合的时间把undo buffer中的内容刷新到磁盘。undo buffer与redo buffer一样,也是环形缓冲,但当缓冲满的时候,undo buffer中的内容会也会被刷新到磁盘;与redo log不同的是,磁盘上不存在单独的undo log文件,所有的undo log均存放在主ibd数据文件中(表空间),即使客户端设置了每表一个数据文件也是如此。


rollback segment

回滚段这个概念来自Oracle的事物模型,在Innodb中,undo log被划分为多个段,具体某行的undo log就保存在某个段中,称为回滚段。可以认为undo log和回滚段是同一意思。




4.2数据的更新过程


初始数据:假设这是刚刚INSERT的数据,可以认为隐含ID为1,其它两个值为NULL

wKioL1V1P7Cxb2vjAAFi1XaYcaU320.jpg



事务1:修改NAME和AGE字段的值

Transacation1

wKiom1V1PozSh4FWAAIOE5OKh4g881.jpg


wKiom1V1QDXShcn0AAGZDcxToIY337.jpg



事务2:修改NAME和AGE字段的值

Transacation2

wKiom1V1QKvS1L72AAMPUPmHh1Y739.jpg