InnoDB中的事务隔离级别和锁的关系
一次封锁or两段锁
因为有大量的并发访问，为了预防死锁，一般应用中推荐一次封锁法，就是在方法的开始阶段，已经预先知道会用到哪些数据，然后全部锁住，在方法运行之后，再全部解锁。这种方式可以有效的避免循环死锁，但在数据库中却不使用，因为在事务开始阶段，数据库并不知道会用到哪些数据。
数据库遵循的是两段锁协议，将事务分成两个阶段，加锁和解锁阶段（因此叫两段锁）：
- 加锁阶段：在该阶段可以进行加锁操作。在对任何数据进行读操作之前要申请并获得S锁（共享锁，其他事务可以继续加共享锁，但不能加排它锁）,在进行写操作之前要申请并获得X锁（排他锁，其他事务不能再获得任何锁）。加锁不成功，则事务进入等待状态，直到加锁成功才继续执行。
- 解锁阶段：当事务释放了一个封锁之后，事务进入解锁阶段，在该阶段只能进行解锁操作不能再进行加锁操作。
| 事务 | 加锁/解锁处理 |
|---|---|
| begin; | |
| insert into test… | 加insert对应的锁 |
| update test set… | 加update对应的锁 |
| delete from test… | 加delete对应的锁 |
| commit | 事务提交时，同时释放insert、update、delete对应的锁 |
这种方式虽然无法避免死锁，但是两段锁协议可以保证事务的并发调度是串行化（串行化很重要，尤其是在数据恢复和备份的时候）
事务中的加锁方式
四种隔离级别
在数据库操作中，为了有效保证并发读取数据的正确性，提出的事务隔离级别。我们的数据库锁，也是为了构建这些隔离级别存在的。
锁的种类
MySQL中常见的有表锁和行锁，也有新加入的元数据锁(meta data lock MDL)等，表锁是对一整张表加锁虽然可分为读锁和写锁，但毕竟是锁住整张表，会导致并发能力下降，一般是做ddl处理时使用。
行锁则是锁住数据行，这种加锁方法比较复杂，但是由于只锁住有限的数据，对于其他数据不加限制，所以并发能力强，MySQL一般都是用行锁来处理数据，这里主要讨论行锁。
Read Committed（读取提交内容）
在RC级别中，数据的读取都是不加锁的，但是数据的写入、修改是需要加锁的。
为了防止并发过程中的修改冲突，事务A中MySQL给teacher_id=1的数据行加锁，并一直不commit（释放锁），那么事务B也就一直拿不到该行锁，wait直到超时。
但是我们注意到，teacher_id是有索引的，如果是没有索引的class_name呢，那么MySQL会给整张表的所有数据行加行锁，这听起来有点不可思议，但是当SQL运行的过程中，MySQL并不知道哪些数据行是class_name=”初三一班“，如果一个条件无法通过索引快速过滤，存储引擎层面就会将所有记录加锁后返回，再由MySQL_Server层进行过滤。
但在实际使用过程中，MySQL做了一些改进，在MySQL_Server过滤条件，发现不满足后，会调用unlock_row方法，把不满足条件的记录释放锁（违背了二段锁的约束）,这样做，保证了最后只有持有满足条件记录上的锁，但是每条记录的加锁操作还是不能省略的。可见即使MySQL，为了效率也是会违反规范的。
这种情况同样适用于MySQL的默认隔离级别RR。所以对一个数据量很大的表做批量修改的时候，如果无法使用相应的索引，MySQL Server过滤数据的时候特别慢，就会出现虽然没有修改某些行的数据，但是它们还是被锁住了的现象。
Repeatable Read(可重读)
这是MySQL中InnoDB默认的隔离级别。我们姑且分为”读“和”写“两个模块来讲解。
读
读就是可重读，可重读这个概念是一事务的多个实例在并发读取数据时，会看到相同的数据行，有点抽象。
不可重复度和幻读的区别
很多人搞不清楚不可重复读和幻读的区别，确实这两者有些相似。但不可重复读重点在于update和delete，而幻读的重点在于insert。
如果使用锁机制来实现这两种隔离级别，在可重复读中，该SQL第一次读取到数据后，就将这些数据加锁，其他事务无法修改这些数据，就可以实现可重复读了。但这种方法却无法锁住insert的数据，所以当事务A先前读取了数据，或者修改了全部数据，事务B还有可以insert数据提交，这是事务A就会发现莫名其妙多了一条之前没有的数据，这就是幻读，不能通过行锁来避免。需要Serializable隔离级别，读用读锁，写用写锁，读锁和写锁互斥，这么做可以有效避免幻读、不可重复读、脏读等，但会极大的降低数据库的并发能力。
所以说不可重复度和幻读最大的区别，就在于如何通过锁机制来解决他们产生的问题。
上文说的是，是使用悲观锁机制来处理这两种问题，但是MySQL、ORACLE、PostgreSQL等成熟的数据库，处于性能考虑，都是使用了以乐观锁为理论基础的MVCC（多版本并发控制）来避免这种问题。
悲观锁和乐观锁
- 悲观锁
正如其名，它指的是对外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
在悲观锁的情况下，为了保证事务的隔离性，就需要一致性锁定读。读取数据时给加锁，其他事务无法修改这些数据。修改删除数据时也要加锁，其他事务无法处读取这些数据。
- 乐观锁
相对悲观锁而言，乐观锁采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据的锁机制实现，以保证操作最大程度的独占性。但随着而来就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。
而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本的记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个字段“version”来实现。读取此数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行对比，如果提交的版本号大于数据表当前版本号，则予以更新，否则认为是过期数据。
MVCC在MySQL的InnoDB中的实现
在InnoDB中，会在每行数据后添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。在可重读Repeatable reads事务隔离级别下：
- SELECT时，读取创建版本号<=当前事务版本号，删除版本号为空或>当前事务版本号
- INSERT时，保存当前事务版本号为行的创建版本号
- DELETE时，保存当前事务版本号为行的删除版本号
- UPDATE时，插入一条新记录，保存当前事务版本号为行创建版本号，同时保存当前事务版本号到原来行。
通过MVCC，虽然每行记录都需要额外的存储空间，更多的行检查工作以及一些额外的维护工作，但可以减少锁的使用，大多数读操作都不用加锁，读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行，也只锁住必要行。
在数据库方面的教科书学到，PR是可重复读的，但无法解决幻读，而只有在Serializable级别才能解决幻读。经测试，在MySQL中是不存在这种情况的，在事务C提交后，事务A还是不会读到这条数据。可见在RR级别中，是解决了幻读的问题的。
“读”和“读”的区别
事务的隔离级别其实都是对于读数据的定义，但到了这里，就被拆成了读和写两个模块来讲解。这主要是因为MySQL中的读，和事务隔离级别中的读，是不一样的。
在RR级别中，通过MVCC机制，虽然让数据变得可重复读，但我们读到的可能是历史数据，是不及时的数据，不是数据库当前的数据！这在一些对于数据的时效性特别敏感的业务中，就很可能出问题。
对于这种读取历史数据的方式，我们叫它快照读，而读取数据库当前版本数据的方式，叫当前读。很显然，在MVCC中：
快照读：即SELECT
SELECT * fron table…
当前读：特殊的读操作，插入/更新/删除操作，属于当前读，处理的都是当前的数据，需要加锁。
SELECT * from table where ？lock in share modes;
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锁。
不仅用行锁锁住了相应的数据行，同时也在两边的区间，加入了gap锁，这样事务B就无法在这两个区间insert进新数据。
受限于这种实现方式，InnoDB很多时候会锁住不需要锁的区间。
如果使用的是没有索引的字段，那么会给全表加入gap锁。同时，它不能像上文中行锁一样经过MySQL Server过滤自动解除不满足条件的锁，因为没用索引，则这些字段也就没有排序，也就没有区间。除非该事务提交，否则其他事务无法插入任何数据。
行锁防止别的事务修改或删除，GAP锁防止别的事务新增，行锁和GAP锁结合形成的Next-KEY锁共同解决了RR级别在写数据时的幻读问题。
Serializable
这个级别很简单，读加共享锁，写加排他锁，读写互斥。使用的悲观的理论，实现简单，数据更加安全，但是并发能力非常差。如果你的业务并发特别少或者没有并发，同时又要求数据及时可靠的话，可以使用这种模式。
注意，不要看到select就说不会加锁了，在Serializable这个级别，还是会加锁的。