mysql 锁、MVCC（多版本控制）

读锁：也叫共享锁、S锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S 锁。这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。

写锁：又称排他锁、X锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。这保证了其他事务在T释放A上的锁之前不能再读取和修改A。

表锁：操作对象是数据表。Mysql大多数锁策略都支持(常见mysql innodb)，是系统开销最低但并发性最低的一个锁策略。事务t对整个表加读锁，则其他事务可读不可写，若加写锁，则其他事务增删改都不行。

行级锁：操作对象是数据表中的一行。是MVCC技术用的比较多的，但在MYISAM用不了，行级锁用mysql的储存引擎实现而不是mysql服务器。但行级锁对系统开销较大，处理高并发较好。

 

 

MVCC的实现，是通过保存数据在某个时间点的快照来实现的，根据事务开始时间的不同，每个事务对于同一张表，同一时刻看到的数据可能是不同的

 InnoDB的 MVCC ，是通过在每行记录的后面保存两个隐藏的列来实现的。这两个列， 一个保存了行的创建时间，一个保存了行的过期时间（或删除时间）， 当然存储的并不是实际的时间值，而是系统版本号。

  

6字节的事务ID（DB_TRX_ID）	表示最后一个事务的更新和插入，（每处理一个事务，其值自动+1）d
7字节的回滚指针（DB_ROLL_PTR）	指向当前记录项的rollback segment的undo log记录，找之前版本的数据就是通过这个指针
6字节的DB_ROW_ID	标识插入的新的数据行的i

MVCC 在mysql 中的实现依赖的是 undo log 与 read view。

 

  read view是干什么的呢？上面可知MVCC实现了多个并发事务更新同一行记录会时产生多个记录版本，那问题来了，新开始的事务如果要查询这行记录，应该获取到哪个版本呢？就需要read view来解决行的可见性问题。

 Read View是事务开启时当前所有事务的一个集合，这个类中存储了当前Read View中最大事务ID及最小事务ID

 

 

总结：

SELECT
　　InnoDB检查每行，要确定它符合两个标准。
　　InnoDB必须知道行的版本号，这个行的版本号至少要和事物版本号一样的老。（也就是是说它的版本号可能少于或者和事物版本号相同）。这个既能确定事物开始之前行是存在的，也能确定事物创建或修改了这行。
　　行的删除操作的版本一定是未定义的或者大于事物的版本号。确定了事物开始之前，行没有被删除。
　　符合了以上两点。会返回查询结果。
INSERT
　　InnoDB记录了当前新增行的系统版本号。
DELETE
　　InnoDB记录的删除行的系统版本号作为行的删除ID。
UPDATE
　　InnoDB复制了一行。这个新行的版本号使用了系统版本号。它也把系统版本号作为了删除行的版本。
    所有其他记录的结果保存是，从未获得锁的查询。这样它们查询的数据就会尽可能的快。要确定查询行要遵循这些标准。缺点是存储引擎要为每一行存储更多的数据，检查行的时候要做更多的处理以及其他内部的一些操作。
    MVCC只能在可重复读和可提交读的隔离级别下生效。不可提交读不能使用它的原因是不能读取符合事物版本的行版本。它们总是读取最新的行版本。可序列化不能使用MVCC的原因是，它总是要锁定行。

看完这些与我之前印象中MVCC还是有较大区别的，以前一直以为不加锁实现了MVCC。就是每行都有版本号，保存时根据版本号决定是否成功，而innodb：

事务以排他锁的形式修改原始数据
把修改前的数据存放于undo log，通过回滚指针与主数据关联

修改成功（commit）啥都不做，失败则恢复undo log中的数据（rollback）

  虽然不是真正意义的MVCC，MVCC对MySQL还有有作用的：

 MVCC使得数据库读不会对数据加锁，select不会加锁，提高了数据库的并发处理能力；
借助MVCC，数据库可以实现RC，RR等隔离级别，用户可以查看当前数据的前一个或者前几个历史版本，保证了ACID中的I-隔离性。