数据库中的锁

数据库中的锁

• 锁分类：
  • 按锁的粒度划分：表级锁、行级锁、页级锁
  • 按锁级别划分：共享锁、排它锁、意向锁
  • 按加锁方式划分：自动锁、显示锁
  • 按使用方式划分：乐观锁、悲观锁

1、从锁的粒度划分：表级锁、行级锁、页级锁来看

• 行级锁：行级锁分为共享锁和排他锁。行级锁是MySQL中锁定粒度最细的锁。行级锁开销大，加锁慢，锁定粒度最小，发生锁冲突的概率最低，并发度最高。

  • MyISAM支持表级锁，InnoDB引擎支持行级锁和表级锁，只有在通过索引条件检索数据的时候，才使用行级锁，否就使用表级锁。

• 表级锁： 表级锁分为表共享（读）锁和表独占（写）锁。表级锁开销小，加锁快，锁定粒度大，发生锁冲突最高，并发度最低

• 页级锁： 页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折中的页级，一次锁定相邻的一组记录。BDB支持页级锁。开销和加锁时间界于表锁和行锁之间；会出现死锁。锁定粒度界于表锁和行锁之间，并发度一般。

2、从锁类型划分：共享锁(读锁)、排它锁(写锁)、意向锁来看

• 共享锁（share lock）：共享锁又叫读锁，如果事务T对A加上共享锁，则其他事务只能对A再加共享锁，不能加其他锁。共享锁的事务只能读数据，不能写数据。

• 排它锁（exclusive lock）：排他锁又叫写锁，如果事务T对A加上排它锁，则其他事务都不能对A加任何类型的锁。获准排它锁的事务既能读数据，又能写数据

• 意向锁：

  • 其实有排它锁和共享锁就足够了为什么还需要有意向锁，这里举一个比较形象的例子：

    在mysql中有表级锁，读锁锁表，会阻塞其他事务修改表数据。写锁锁表，会阻塞其他事务读和写。

    1. Innodb引擎又支持行锁，行锁分为共享锁，一个事务对一行的共享只读锁。排它锁，一个事务对一行的排他读写锁。
    2. 这两中类型的锁共存的问题考虑这个例子：事务A锁住了表中的一行，让这一行只能读，不能写。之后，事务B申请整个表的写锁。如果事务B申请成功，那么理论上它就能修改表中的任意一行，这与A持有的行锁是冲突的。数据库需要避免这种冲突，就是说要让B的申请被阻塞，直到A释放了行锁。

  • 数据库要怎么判断这个冲突呢？

    • step1：判断表是否已被其他事务用表锁锁表
    • step2：判断表中的每一行是否已被行锁锁住。

    （注意step2，这样的判断方法效率实在不高，因为需要遍历整个表。于是就有了意向锁。在意向锁存在的情况下，事务A必须先申请表的意向共享锁，成功后再申请一行的行锁。）

  • 在意向锁存在的情况下，上面的判断可以改成

    • step1：不变
    • step2：发现表上有意向共享锁，说明表中有些行被共享行锁锁住了，因此，事务B申请表的写锁会被阻塞。

    （注意：申请意向锁的动作是数据库完成的，就是说，事务A申请一行的行锁的时候，数据库会自动先开始申请表的意向锁，不需要我们程序员使用代码来申请。）

3、从加锁方式划分：自动锁、显示锁来看

• 自动锁：存储引擎例如InnoDB的，MyISAM，都会自动给数据加锁，不需要用户参与，大体上都是在执行查询语句（SELECT）前，会自动给涉及的所有数据集（表，MyISAM只有表级锁）加读锁，在执行更新操作（UPDATE、DELETE、INSERT等）前，会自动给涉及的数据集（表）加写锁，

• 显示锁：显示加锁就是在手写sql语句时，加上锁的语句，例如

  • MyISAM中：

    SELECT SUM(total) FROM orders;
    SELECT SUM(subtotal) FROM order_detail;
    
    //加锁之后
    LOCK tables orders read local,order_detail read local;
    SELECT SUM(total) FROM orders;
    SELECT SUM(subtotal) FROM order_detail;
    Unlock tables;
    

  • InnoDB中：

    共享锁（读锁）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE
    
    排他锁（写锁）：SELECT * FROM table_name WHERE ... FOR UPDATE
    

4、使用方式划分：乐观锁、悲观锁(写锁)来看

• 悲观锁(悲观并发控制)：就是对数据的冲突采取一种悲观的态度，也就是说假设数据肯定会冲突，所以在数据开始读取的时候就把数据锁定住。【数据锁定：数据将暂时不会得到修改】

• 乐观锁(乐观并发控制)：认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让用户返回错误的信息。让用户决定如何去做。

• 并发控制的主要采用的技术手段：乐观锁、悲观锁和时间戳。

理解

• 乐观锁是一种思想，具体实现是，表中有一个版本字段，第一次读的时候，获取到这个字段。处理完业务逻辑开始更新的时候，需要再次查看该字段的值是否和第一次的一样。如果一样更新，反之拒绝。之所以叫乐观，因为这个模式没有从数据库加锁。
• 乐观锁，优点程序实现，不会存在死锁等问题。他的适用场景也相对乐观。阻止不了除了程序之外的数据库操作。
• 悲观锁是读取的时候为后面的更新加锁，之后再来的读操作都会等待。这种是数据库锁
• 悲观锁是数据库实现，他阻止一切数据库操作。

实现

• 悲观锁：

  • 排它锁，当事务在操作数据时把这部分数据进行锁定，直到操作完毕后再解锁，其他事务操作才可操作该部分数据。这将防止其他进程读取或修改表中的数据。

  • 实现：大多数情况下依靠数据库的锁机制实现

    一般使用 select …for update 对所选择的数据进行加锁处理，例如select * from account where name=”Max” for update， 这条sql 语句锁定了account 表中所有符合检索条件（name=”Max”）的记录。本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。

• 乐观锁：

  • 如果有人在你之前更新了，你的更新应当是被拒绝的，可以让用户重新操作。

  • 实现：大多数基于数据版本（Version）记录机制实现

    具体可通过给表加一个版本号或时间戳字段实现，当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断当前版本信息与第一次取出来的版本值大小，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据，拒绝更新，让用户重新操作。

5、数据库存储引擎中的锁

5.1、MyISAM的锁

• 在使用MyIsam时，我们只可以使用表级锁，而MySQL的表级锁有两种模式：

  表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock），他们在工作时表现如下：

  • 对某一个表的读操作，不会阻塞其他用户对同一表请求，但会阻塞对同一表的写请求；
  • 对MyISAM的写操作，则会阻塞其他用户对同一表的读和写操作；
  • MyISAM表的读操作和写操作之间，以及写操作之间是串行的。

  当一个线程获得对一个表的写锁后，只有持有锁的线程可以对表进行更新操作。其他线程的读、写操作都会等待，直到锁被释放为止。

5.2、InnoDB的锁

• InnoDB引擎支持行级锁和表级锁，只有在通过索引条件检索数据的时候，才使用行级锁，否就使用表级锁。

• InnoDB实现了以下两种类型的行锁。

  • 共享锁（读锁，S）：允许一个事务去读一行，阻止其他事务对该数据进行修改。

  • 排他锁（写锁，X）：允许获取排他锁的事务更新数据，阻止其他事务对数据进行查询或者修改。

  • 另外，行锁虽然很赞，但是还有一个问题，如果一个事务对一张表的某条数据进行加锁，这个时候如果有另外一个线程想要用LOCK TABLES进行锁表，这时候数据库要怎么知道哪张表的哪条数据被加了锁，一张张表一条条数据去遍历是不可行的。InnoDB考虑到这种情况，设计出另外一组锁：意向共享锁（IS）和意向排他锁(IX)。 目的也是为了允许行锁和表锁共存，实现多粒度锁机制，这两种意向锁都是表锁同时也是InnoDB内部使用的意向锁（Intention Locks）。

    • 意向共享锁（IS）：当一个事务要给一条数据加S锁的时候，会先对数据所在的表先加上IS锁，成功后才能加上S锁。
    • 意向排他锁（IX）：当一个事务要给一条数据加X锁的时候，会先对数据所在的表先加上IX锁，成功后才能加上X锁。
    • 意向锁之间兼容，不会阻塞。但是会跟S锁和X锁冲突，冲突的方式跟读写锁相同。例如当一张表上已经有一个排它锁（X锁），此时如果另外一个线程要对该表加意向锁，不管意向共享锁还是意向排他锁都不会成功。

• 当前锁模式/是否兼容/请求锁模式	排他锁	意向排他锁	共享锁	意向共享锁
  排他锁	冲突	冲突	冲突	冲突
  意向排他锁	冲突	兼容	冲突	兼容
  共享锁	冲突	冲突	兼容	兼容
  意向共享锁	冲突	兼容	兼容	兼容

  如果一个事务请求的锁模式与当前的锁兼容，InnoDB就请求的锁授予该事务；反之，如果两者两者不兼容，该事务就要等待锁释放。

• 意向锁是InnoDB自动加的，不需用户干预。对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及的数据集加排他锁（Ｘ）；对于普通SELECT语句，InnoDB会自动给涉及数据集加共享锁（S）；事务可以通过以下语句显式给记录集加共享锁或排锁。

  共享锁（Ｓ）：SELECT * FROM table_name WHERE … LOCK IN SHARE MODE

  排他锁（X）：SELECT * FROM table_name WHERE … FOR UPDATE

  用SELECT … IN SHARE MODE获得共享锁，主要用在需要数据依存关系时确认某行记录是否存在，并确保没有人对这个记录进行UPDATE或者DELETE操作。但是如果当前事务也需要对该记录进行更新操作，则很有可能造成死锁，对于锁定行记录后需要进行更新操作的应用，应该使用SELECT … FOR UPDATE方式获取排他锁。