一、数据库机制
悲观锁：
数据库总是认为多个数据库并发操作会发生冲突，所以总是要求加锁操作。悲观锁主要表锁、行锁、页锁。
乐观锁：
数据库总是认为多个数据库并发操作不会发生冲突，所以总是不加锁操作。所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信 息，让用户决定如何去做。乐观锁的实现方式一般包括使用版本号和时间戳。
表级锁：
读锁锁表，会阻碍其他事务修改表数据。写锁锁表会阻碍其他事务读与写。
页级锁：
就是对页加锁
行级锁：
行锁分为共享锁和排他锁，共享锁：一个事务对一行的共享只读锁。排它锁：一个事务对一行的排他读写锁。
共享锁：
加锁与解锁：当一个事务执行select语句时，数据库系统会为这个事务分配一把共享锁，来锁定被查询的数据。在默认情况下，数据被读取后，数据库系统立即解除共享锁。例如，当一个事务 执行查询“SELECT * FROM accounts”语句时，数据库系统首先锁定第一行，读取之后，解除对第一行的锁定，然后锁定第二行。这样，在一个事务读操作过程中，允许其他事务同时更新 accounts表中未锁定的行。
兼容性：如果数据资源上放置了共享锁，还能再放置共享锁和更新锁。
并发性能：具有良好的并发性能，当数据被放置共享锁后，还可以再放置共享锁或更新锁。所以并发性能很好。
排它锁：
加锁与解锁：当一个事务执行insert、update或delete语句时，数据库系统会自动对SQL语句操纵的数据资源使用独占锁。如果该数据资源已经有其他锁（任何锁）存在时，就无法对其再放置 独占锁了。
兼容性：独占锁不能和其他锁兼容，如果数据资源上已经加了独占锁，就不能再放置其他的锁了。同样，如果数据资源上已经放置了其他锁，那么也就不能再放置独占锁了。
并发性能：最差。只允许一个事务访问锁定的数据，如果其他事务也需要访问该数据，就必须等待。
更新锁：
加锁与解锁：当一个事务执行update语句时，数据库系统会先为事务分配一把更新锁。当读取数据完毕，执行更新操作时，会把更新锁升级为独占锁。
兼容性：更新锁与共享锁是兼容的，也就是说，一个资源可以同时放置更新锁和共享锁，但是最多放置一把更新锁。这样，当多个事务更新相同的数据时，只有一个事务能获得更新锁，然后 再把更新锁升级为独占锁，其他事务必须等到前一个事务结束后，才能获取得更新锁，这就避免了死锁。
并发性能：允许多个事务同时读锁定的资源，但不允许其他事务修改它。
意向锁（意向共享，意向更新）：
在判断每一行是否已经被行锁锁定效率比较低下，因此使用意向锁，当发现表上有意向共享锁，说明表中有些行被共享行锁锁住了，因此，事务B申请表的写锁会被阻塞。
二 MVCC
在讲解InnoDB的MVCC机制之前，我们应该了解MySQL所支持的事务,以及各个事务级别的区别和每一个事务级别所存在的问题。
1. 事务：
事务必须保证ACID，而ACID表示原子性、一致性、隔离性和持久性
1.1 事务的隔离级别
事务可以通过start transaction语句开始一个事务，然后要么使用commit提交事务将所修改的数据持久保存，要么使用rollback撤销所有修改
1.1.2 READ UNCOMMITTED （未提交读 RU）
在READ UNCOMMITTED级别，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读。
1.1.3 READ COMMITTED （提交读 RC）
大多数的数据库系统的默认隔离级别都是READ COMMITTED（MySQL 不是）。READ COMMITTED满足前面提到的隔离级别的简单定义：一个事务开始时，只能“看见” 已提交的事务所做的修改。换句话说，一个事务从开始知道提交之前，所做的任何修改对其他事务都是不可见的。这个级别也叫不可重复读，因为在同一事务内执行两次相同的查询，可能会得到不一样的结果。
例子： 当事务的隔离级别在RC级别的时候，事务A和事务B同时对数据D操作，当事务A开始的时候，读取的数据D保存下来了，这是事务B也在修改数据D，并且先于事务A提交。这是事务A再读数据D的时候，就会出现前后不一致情况，这就是所谓的不可重复读。
1.1.4 REPEATABLE READ （可重复读 RR）
这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。
例子：mysql的默认事务隔离级别是RR级别的，同样是上述例子，当时不同的是当事务A和事务B开始的时候，都保存一份自己的快照，每一份快照中都有数据D的值，所以这样在同一事务中，无论重读读多少次都是正确的。
例子：在RR级别中，可能出现幻读。同样是上述例子，事务A和事务B同时查询数据D，事务A发现数据D为空，就想插入数据，但是这是事务B已经插入了数据D并且已经提交。这时事务A的提交就会出错。这是因为事务A的写操作是当前读操作。
1.1.5 SERIALIZABLE （可串行化 S）
这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。
2. MVCC机制
InnoDB的一致性的非锁定读就是通过在MVCC实现的，Mysql的大多数事务型存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑，它们一般都同时实现了多版本并发控制（MVCC）。MVCC的实现，是通过保存数据在某一个时间点的快照来实现的。因此每一个事务无论执行多长时间看到的数据，都是一样的。所以MVCC实现可重复读。
快照读：select语句默认，不加锁，MVCC实现可重复读，使用的是MVCC机制读取undo中的已经提交的数据。所以它的读取是非阻塞的
当前读：select语句加S锁或X锁；所有的修改操作加X锁，在select for update 的时候，才是当地前读。
RR隔离级别下的快照读，不是以begin开始的时间点作为snapshot建立时间点，而是以第一条select语句的时间点作为snapshot建立的时间点。
2.1. MVCC依赖数据
行记录隐藏字段
db_row_id，行ID，用来生成默认聚簇索引（聚簇索引，保存的数据在物理磁盘中按顺序保存，这样相关数据保存在一起，提高查询速度）
db_trx_id，事务ID，新开始一个事务时生成，实例内全局唯一
db_roll_ptr，undo log指针，指向对应记录当前的undo log
deleted_bit，删除标记位，删除时设置
undo log
用于行记录回滚，同时用于实现MVCC
2.2 操作方式
update
行记录数据写入undo log,事务的回滚操作就需要undo log
更新行记录数据，当前事务ID写入db_trx_id，undo log指针写入db_roll_ptr
delete
和update一样，只增加deleted_bit设置
insert
生成undo log
插入行记录数据，当前事务ID写入db_trx_id， db_roll_ptr为空
这样设计使得读操作很简单，性能很好，并且也能保证只会读到符合标准的行，不足之处是每行记录都需要额外的储存空间，需要做更多的行检查工作，以及额外的维护工作
2.3 MVCC如何实现RR
RR定义：在一个事务内同一快照读执行任意次数，得到的数据一致；且只能读到第一次执行前已经提交的数据或本事务内更改的数据
原理：对符合查询条件的记录进行可见性判断（就是那些数据本事务可以看见，那些数据看不见）
read view：记录当前处于活动状态的所有事务ID，RR级别下，第一次快照读时创建，RC级别下，每次快照读均会创建新的
缺点： 可能出现幻读
3 总结
在事务隔离级别为RC和RR级别下， InnnoDB存储引擎使用的才是多版本并发控制。然而，对于快照数据的定义却不相同。在RC事务隔离级别下，对于快照数据（undo端数据），总是读取被锁定行的最新的一份快照数据。而在RR事务隔离级别下，对于快照数据，多版本并发控制总是读取事务开始时的行数据。
三 事务隔离机制
事务中的加锁方式
事务的四种隔离级别
在数据库操作中，为了有效保证并发读取数据的正确性，提出的事务隔离级别。我们的数据库锁，也是为了构建这些隔离级别存在的。
未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据
提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)
可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读
串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞
Read Uncommitted这种级别，数据库一般都不会用，而且任何操作都不会加锁，这里就不讨论了。
MVCC在MySQL的InnoDB中的实现
在InnoDB中，会在每行数据后添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。 在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。 在可重读Repeatable reads事务隔离级别下：
SELECT时，读取创建版本号<=当前事务版本号，删除版本号为空或>当前事务版本号。
INSERT时，保存当前事务版本号为行的创建版本号
DELETE时，保存当前事务版本号为行的删除版本号
UPDATE时，插入一条新纪录，保存当前事务版本号为行创建版本号，同时保存当前事务版本号到原来删除的行
通过MVCC，虽然每行记录都需要额外的存储空间，更多的行检查工作以及一些额外的维护工作，但可以减少锁的使用，大多数读操作都不用加锁，读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行，也只锁住必要行。
我们不管从数据库方面的教课书中学到，还是从网络上看到，大都是上文中事务的四种隔离级别这一模块列出的意思，RR级别是可重复读的，但无法解决幻读，而只有在Serializable级别才能解决幻读。于是我就加了一个事务C来展示效果。在事务C中添加了一条teacher_id=1的数据commit，RR级别中应该会有幻读现象，事务A在查询teacher_id=1的数据时会读到事务C新加的数据。但是测试后发现，在MySQL中是不存在这种情况的，在事务C提交后，事务A还是不会读到这条数据。可见在MySQL的RR级别中，是解决了幻读的读问题的。
“读”与“读”的区别
可能有读者会疑惑，事务的隔离级别其实都是对于读数据的定义，但到了这里，就被拆成了读和写两个模块来讲解。这主要是因为MySQL中的读，和事务隔离级别中的读，是不一样的。
我们且看，在RR级别中，通过MVCC机制，虽然让数据变得可重复读，但我们读到的数据可能是历史数据，是不及时的数据，不是数据库当前的数据！这在一些对于数据的时效特别敏感的业务中，就很可能出问题。
对于这种读取历史数据的方式，我们叫它快照读 (snapshot read)，而读取数据库当前版本数据的方式，叫当前读 (current read)。很显然，在MVCC中：
快照读：就是select
select * from table ….;
当前读：特殊的读操作，插入/更新/删除操作，属于当前读，处理的都是当前的数据，需要加锁。
select * from table where ? lock in share mode;
select * from table where ? for update;
insert;
update ;
delete;
事务的隔离级别实际上都是定义了当前读的级别，MySQL为了减少锁处理（包括等待其它锁）的时间，提升并发能力，引入了快照读的概念，使得select不用加锁。而update、insert这些“当前读”，就需要另外的模块来解决了。
写（”当前读”）
事务的隔离级别中虽然只定义了读数据的要求，实际上这也可以说是写数据的要求。上文的“读”，实际是讲的快照读；而这里说的“写”就是当前读了。
为了解决当前读中的幻读问题，MySQL事务使用了Next-Key锁。
Next-Key锁
Next-Key锁是行锁和GAP（间隙锁）的合并，行锁上文已经介绍了，接下来说下GAP间隙锁。
行锁可以防止不同事务版本的数据修改提交时造成数据冲突的情况。但如何避免别的事务插入数据就成了问题。我们可以看看RR级别和RC级别的对比
RR级别中，事务A在update后加锁，事务B无法插入新数据，这样事务A在update前后读的数据保持一致，避免了幻读。这个锁，就是Gap锁。
MySQL是这么实现的：
在class_teacher这张表中，teacher_id是个索引，那么它就会维护一套B+树的数据关系，为了简化，我们用链表结构来表达（实际上是个树形结构，但原理相同）
行锁防止别的事务修改或删除，GAP锁防止别的事务新增，行锁和GAP锁结合形成的的Next-Key锁共同解决了RR级别在写数据时的幻读问题。
Serializable
这个级别很简单，读加共享锁，写加排他锁，读写互斥。使用的悲观锁的理论，实现简单，数据更加安全，但是并发能力非常差。如果你的业务并发的特别少或者没有并发，同时又要求数据及时可靠的话，可以使用这种模式。
这里要吐槽一句，不要看到select就说不会加锁了，在Serializable这个级别，还是会加锁的！