MySQL锁和隔离机制

一：MySQL锁

二：MySQL事务

三：MySQL隔离级别

四：MVCC

1.1为何要有锁？

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

1.2锁的分类

    1.2.1按对数据的操做类型

        LOCK TABLES tb_namelock_type{READ|WRITE};

        UNLOCKTABLES ;

        读锁（共享锁）：针对同一块数据，多个读操做能够同时进行而不会互相影响。

                        写锁（排它锁）：当前写操做没有完成前，它会阻断其余写锁和读锁。

   

        示例1：读锁

            

            

            

            

        示例2：写锁

              

              

              

              

    

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

        表锁：管理锁的开销最小，同时容许的并发量也最小的锁机制。MyIsam存储引擎使用的锁机制。当要写入数据时，把整个表都锁上，此时其余读、写动做一概等待。在MySql中，除了MyIsam存储引擎使用这种锁策略外，MySql自己也使用表锁来执行某些特定动做，好比alter table.

 

        行锁：能够支持最大并发的锁策略。InnoDB存储引擎采用这种策略

2.1 ACID

    原子性（Autmic）：事务所引发的数据库操做，要么都完成，要么都不执行

        

    一致性（Consistency）：完成以前和完成以后是同样的（两个账户的钱，转帐以前和以后的总和是同样的）

        

    隔离性（Isolation）：一个事务的执行不能影响另外一个事务的执行

        

    持久性（Durability）：一旦事务成功完成，系统必须保证任何故障都不能引发事务的不一致性。

2.2事务的状态

    

2.3保存点（SAVEPOINT）

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

    撤销？？---->80个都撤销了--->很差

        

    这样就引出保存点了，每10个作一次保存点

 

    回滚保存点：ROLLBACK TO sid

    

    示例：

    

    

3.1事务的隔离级别

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

                  

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

                  

    REPEATABLE-READ：可重读 

        （无论别的事务是否提交，个人事务以内看到的依然是同样的，例如A事务执行了UPDATE操    

            做，B事务执行SELECT操做，在A执行前和后,B执行的结果都同样）

                  

    SERIALIZABLE：可串行化

        

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

        SHOW GLOBAL VARIABLES LIKE '%ISO%';

        SELECT @@TX_ISOLATION;

    

    

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

3.2.1READ-UNCOMMITTED示例

【客户端1】

【客户端2】

【客户端1】

【客户端2】

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

3.2.2READ-COMMITTED

【客户端1】

【客户端2】

【客户端1】

【客户端2】

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

3.2.3REPEATABLE-READ

【客户端1】

【客户端2】

【客户端1】

【客户端2】

总结：客户端2在提交前和提交后看到的数据依然不同，产生了幻读

3.2.4SERIALIZABLE

【客户端1】

【客户端2】

【客户端1】

【客户端2】

总结：虽然不存在数据幻读的问题，可是执行效率很是低

如下内容来自于：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

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

Transacation1

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

Transacation2