MySQL 悲观锁和乐观锁

MySQL的表级锁（MyIsAm）有两种模式：表共享读锁（Table Read Lock）和表独占写锁（Table
Write Lock）。 

MySQL的行级锁（InnoDB）有两种模式：共享锁：

SELECT
... LOCK IN SHARE MODE

和 共享锁：

SELECT
... LOCK IN SHARE MODE

。 

1.悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系 统不会修改数据）。

数据库锁机制:

1        未提交读（read uncommitted）

2        提交读（read committed）

3        重复读（repeatable read）

4        序列化（serializable）

锁机制：

   共享锁：其他事务可以读，但不能修改。

   排他锁：其他事务不能读取。

锁粒度：一般分为：行锁（最小）、表锁、库锁

解释：

 1 未提交读（read uncommitted）

         一个更新数据库的事务A在未commit的情况下，另一个事务B正在读取事务A更新的记录，会产生脏读现象，这是因为A事务在开启 DB Transaction后，做一些DML操作时，记录会保存在内存中，这时B事务读取了A事务提交在内存中的数据，产生了脏读。

2 提交读（read committed）

        数据的修改只有在commit之后，才回被读取。和1 相反。

3 重复读（repeatable read）

      当数据库隔离级别设置成 repeatable read后，事务A中的select 的过程中事务B可以修改A读取部分的数据，当A第2次执行同样的sql时，返回和上次相同的数据 ，消除不可重复读。

    注：个人认为只是应为A事务采用这种隔离级别后，读取的是数据库在事务开始时间点的映象，在这个时间点后的所有操作都不会对A事务中的查询产生影响，依据是本文后续的实验，如果有疑问，请指出。

4 序列化（serializable）

      当数据库隔离级别设置成Serializeable后，事务A中的select 会以共享锁锁定相关的数据（在select 返回的数据结果集），这些数据不可以被修改（可以被读取），若事务B对这些数据做UPDATE操作，会处于等待状态，消除幻读。

     注：事务B可以UPDATE 事务A中为锁定的数据，后面的实验可以证明。

 

 

2、乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库 性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。 而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如
果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。