表锁和行锁哪个执行的更快

约定不等于承诺〃 2021-12-18 13:43 267阅读 0赞

[https://blog.csdn.net/persistencegoing/article/details/84376427][https_blog.csdn.net_persistencegoing_article_details_84376427]

锁定对象可以是逻辑单元（如数据库、表、记录、列、索引等），也可以是物理单元（如数据页、索引页等）。锁定对象的大小被称为锁定的粒度（granularity）。锁定的粒度与系统的并发度和并发控制的开销密切相关。一般地，锁定的粒度越大，需要锁定的对象就越少，可选择性就越小，并发度就越小，开销就越小；反之，锁定的粒度越小，需要锁定的对象就越多，可选择性就越大，并发度就越大，开销就越大。

表锁需要维护的锁的数量要比行锁少，所以行锁对于锁的维护成本高。但是对于同一个表的操作，比如先在最后一行添加一行数据，然后再修改其它行的数据，这种情况行锁要快的。所以说，很难说表锁快，还是行锁快？例如，如果锁定的粒度是表，事务T1需要操作表A中的记录r1，则T1必须对包含记录r1的表A加锁。在T1对A加锁之后，事务T2需要操作表A中的记录r2，因此就需要对表A加锁，但此时因为T1已经在表A上加了锁，所以T2的加锁就会失败，就被迫等待，直到T1释放锁为止，事务T1和T2就不能并发执行了；如果锁定的粒度是行记录，则事务T1可以对表A中的记录r1加锁，同时事务T2也可以对表A中的记录r2加锁，所以事务T1和T2就可以并发执行了，并发度就增大了，但维护这个并发度就需要更多的开销了。

从前面的例子可知，选择锁定粒度时应该同时考虑并发度与开销两个因素。以求最优的效果。一般地，需要处理大量记录的事务可以以表为锁定粒度；需要处理多个表中的大量记录的事务可以以数据库为锁定粒度；而只需要处理某个表中少量记录的事务，则可以以行记录为锁定粒度。

多粒度锁定协议是指，允许对多粒度树中的节点单独地加锁，另外，对一个节点加锁还意味着对这个节点的各级子节点也加同样的锁。因此，可以用两种方法对多粒度树中的节点加锁：显式锁定、隐式锁定。显式锁定是在事务中明确指定要加在节点上的锁；隐式锁定是由于在其上级节点中加显式锁时而使该节点获得的锁。  
  
         在多粒度锁定中，显式锁定与隐式锁定的作用与相容规则都是一样的。因此，当系统检查锁定的冲突时，不仅要检查显式锁定还要检查隐式锁定。  
  
          一般地，当对一个节点加锁时，系统第一要检查在该节点上有无显式锁定与之冲突；第二要检查其所有上级节点有无显式锁定与之冲突，以便查看在该节点上加该显式锁定，是否会与从上级节点获得的隐式锁定有冲突；第三要检查所有下级节点有无显式锁定与之冲突，以便查看在该节点上加该显式锁定，是否会使下级节点从该节点获得的隐式锁定与其显式锁定有冲突。这种检查锁定冲突的方法的效率很低，所以引进了意向锁（Intended lock）的概念。

## ##

### 意向锁的含义 ###

**        意向锁**的含义是如果对一个结点加**意向锁**，则说明该结点的下层结点正在被加锁；对任一结点加锁时，必须先对它的上层结点加**意向锁**。  
       例如，对任一元组加锁时，必须先对它所在的关系加**意向锁**。于是，事务T要对关系R1加 X锁时，系统只要检查根结点[数据库][Link 1]和关系R1是否己加了不相容的锁，而不再需要搜索和检查尺中的每一个元组是否加了X锁。  
      下面介绍三种常用的**意向锁**：意向共享锁（Intent [Share][] Lock，简称IS锁）；意向排它锁（Intent Exclusive Lock，简称IX锁）；共享意向排它锁（[Share][] Intent Exclusive Lock，简称SIX锁）。

### 意向锁的作用 ###

引进**意向锁**是为了提高封锁子系统的效率。该封锁子[系统支持][Link 2]多种封[锁粒度][Link 3]。原因是：在多粒度[封锁方法][Link 4]中一个[数据对象][Link 5]可能以两种方式加锁 ― 显式封锁和隐式封锁。因此系统在对某一[数据对象][Link 5]加锁时不仅要检查该[数据对象][Link 5]上有无（显式和隐式）封锁与之冲突，还要检查其所有上级结点和所有下级结点，看申请的封锁是否与这些结点上的（显式和隐式）封锁冲突，显然，这样的检查方法效率很低。为此引进了**意向锁**。**意向锁**的含义是：对任一结点加锁时，必须先对它的上层结点加**意向锁**。例如事务 T 要对某个元组加 X 锁，则首先要对关系和[数据库][Link 1]加 ix 锁。换言之，对关系和[数据库][Link 1]加 ix 锁，表示它的后裔结点 ― 某个元组拟（意向）加 X 锁。引进**意向锁**后，系统对某一[数据对象][Link 5]加锁时不必逐个检查与下一级结点的封锁冲突了。例如，事务 T 要对关系 R 加 X 锁时，系统只要检查根结点[数据库][Link 1]和 R 本身是否已加了不相容的锁（如发现已经加了 ix ，则与 X 冲突），而不再需要搜索和检查 R 中的每一个元组是否加了 X 锁或 S 锁。备注:  IX  意向排它锁，IS 意向读锁，X 排它锁，S 共享锁

如果只考虑速度，当然是表锁快，最起码行锁加了以后还要加意向锁 表锁则不需要，但如果考虑到并发冲突，行锁显然会减少冲突，这样并发进程的平均等待时间会少。不过比较锁的快慢没有任何意义，显然应该比较的是在不同粒度锁的情况下插入更新删除的速度

**希望大家关注我一波,防止以后迷路,有需要的可以加群讨论互相学习java ,学习路线探讨,经验分享与java求职     **

**群号:721 515 304**

[https_blog.csdn.net_persistencegoing_article_details_84376427]: https://blog.csdn.net/persistencegoing/article/details/84376427
[Link 1]: https://link.jianshu.com?t=http://term.ccf.org.cn/index.php/%E6%95%B0%E6%8D%AE%E5%BA%93
[Share]: https://link.jianshu.com?t=http://term.ccf.org.cn/index.php/Share
[Link 2]: https://link.jianshu.com?t=http://term.ccf.org.cn/index.php/%E7%B3%BB%E7%BB%9F%E6%94%AF%E6%8C%81
[Link 3]: https://link.jianshu.com?t=http://term.ccf.org.cn/index.php/%E9%94%81%E7%B2%92%E5%BA%A6
[Link 4]: https://link.jianshu.com?t=http://term.ccf.org.cn/index.php/%E5%B0%81%E9%94%81%E6%96%B9%E6%B3%95
[Link 5]: https://link.jianshu.com?t=http://term.ccf.org.cn/index.php/%E6%95%B0%E6%8D%AE%E5%AF%B9%E8%B1%A1