事务特性

  • 原子性
  • 隔离性
  • 持久性

  • 一致性

    并发事务存在问题

  • 脏读（Dirty read）: 当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。

  • 丢失修改（Lost to modify）: 指在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。 例如：事务1读取某表中的数据A=20，事务2也读取A=20，事务1修改A=A-1，事务2也修改A=A-1，最终结果A=19，事务1的修改被丢失。
  • 不可重复读（Unrepeatableread）: 指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。
  • 幻读（Phantom read）: 幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。

事务隔离级别

  • READ-UNCOMMITTED(读取未提交)： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
  • READ-COMMITTED(读取已提交)： 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
  • REPEATABLE-READ(可重复读)： 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。

SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读），但是可以通过应用加锁读（例如 select * from table for update 语句）来保证不会产生幻读，而这个加锁度使用到的机制就是 Next-Key Lock 锁算法。从而达到了 SQL 标准的 SERIALIZABLE(可串行化) 隔离级别。

锁的分类

读写分类

  • LOCK_IS：读意向锁；
  • LOCK_IX：写意向锁；
  • LOCK_S：读锁；又称读锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。
  • LOCK_X：写锁；又称写锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁
  • LOCK_AUTO_INC：自增锁（AUTO_INC 表锁 0 ）

innodb_autoinc_lock_mode = 1 （consecutive lock mode） 自增锁分类设置
兼容性：

  • 意向锁之间互不冲突；
  • S 锁只和 S/IS 锁兼容，和其他锁都冲突；
  • X 锁和其他所有锁都冲突；

  • AI 锁只和意向锁兼容；

    锁粒度

  • 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。（DDL,无索引更新，事务级别为RR,Serializable）

  • 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
  • Gap锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

    InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。 InnoDB这种行锁实现特点意味着：只有通过**索引**条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用Next-Key Locks！(RU和RC，无论条件列上是否有索引，都不会锁表，只锁行！)

应用：
select * from table where pId = 2 for update；
如果pid 没有索引，会全表加行锁，然后扫码释放。 如果有一级索引，直接在该一级索引行加锁；如果是二级索引，在该二级索引加锁,查找该行一级索引，加锁

悲观锁和乐观锁

悲观锁和乐观锁是抽象应用，不真实存在这个锁

  • 悲观锁

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

  • 乐观锁

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

MVCC在MySQL的InnoDB中的实现(乐观锁)

在InnoDB中，会在每行数据后添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。 在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。 在可重读Repeatable reads事务隔离级别下：

  • SELECT时，读取创建版本号<=当前事务版本号，删除版本号为空或>当前事务版本号。
  • INSERT时，保存当前事务版本号为行的创建版本号
  • DELETE时，保存当前事务版本号为行的删除版本号
  • UPDATE时，插入一条新纪录，保存当前事务版本号为行创建版本号，同时保存当前事务版本号到原来删除的行

通过MVCC，虽然每行记录都需要额外的存储空间，更多的行检查工作以及一些额外的维护工作，但可以减少锁的使用，大多数读操作都不用加锁，读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行，也只锁住必要行。

“读”与“读”的区别

  • 快照读：就是select
    • select * from table ….;
  • 当前读：特殊的读操作，插入/更新/删除操作，属于当前读，处理的都是当前的数据，需要加锁。
    • select from table where ? lock in share mode; （*当前读，s锁）
    • select from table where ? for update; （*当前读,x锁）
    • insert;
    • update ;
    • delete;

      Next-Key锁

      Next-Key锁是行锁和GAP（间隙锁）的合并，行锁上文已经介绍了，接下来说下GAP间隙锁。
      GAP锁是避免别的事务插入数据造成问题。（隔离级别为Repeatable Read和Serializable时，就会存在间隙锁）
      事务A
      update class_teacher set class_name=’初一一班’ where teacher_id=20; // 锁住teacher_id 开始到结束区间段;
      事务B
      insert into class_teacher values (null,’初三五班’,10); // 需要等待
      事务C
      insert into class_teacher values (null,’初三五班’,40);

意向锁

  • 意向共享锁(IS锁):一个事务在获取（任何一行/或者全表）S锁之前，一定会先在所在的表上加IS锁。
  • 意向排他锁(IX锁):一个事务在获取（任何一行/或者全表）X锁之前，一定会先在所在的表上加IX锁。

    意向锁作用：

    假设事务T1，用X锁来锁住了表上的几条记录，那么此时表上存在IX锁，即意向排他锁。那么此时事务T2要进行LOCK TABLE … WRITE的表级别锁的请求，可以直接根据意向锁是否存在而判断是否有锁冲突。

锁优化：
在查询字段尽量加索引，索引值尽量差异读较大。
mysql 默认是 RR 隔离级别，使用 next-key 锁；锁加在聚簇索引上
RR 解决幻读原理：
查询：快照读，使用 mvcc快照，基于undolog, 事务版本号
更新：当前读，使用 next-key锁；
避免升级表锁：

  • alter table;
  • 更新表格加 where 条件，避免 查询条件类型转化；
  • 控制事务大小，减少锁定的资源量和锁定时间长度。
  • 所有的数据检索都通过索引来完成，从而避免因为无法通过索引加锁而升级为表锁。
  • 减少基于范围的数据检索过滤条件，避免因为间隙锁带来的负面影响而锁定了不该锁定的数据。

参考文档:
https://tech.meituan.com/2014/08/20/innodb-lock.html
https://www.cnblogs.com/rjzheng/p/9950951.html
https://zhuanlan.zhihu.com/p/67793185