详解数据库锁机制和原理（转载）

毕竟时间管理大师是一个用户访问多个资源，今天咱们来讲讲当多个用户并发访问同一个资源时的情况

在数据库中，如果多个事务同时对一个数据进行操作，并发的操作若不加控制，可能会读取和存储不正确的数据，破坏数据库的一致性、脏读、不可重复读、幻读等、甚至可能产生死锁。

为了解决这个问题，加锁是一个非常重要的技术，对实现数据库并发控制是一个好的方案。

简单说，当一个执行 sql 语句的事务想要操作表记录之前，先向数据库发出请求，对你访问的记录加锁，在这个事务释放这个锁之前，其他事务不能对这些数据进行更新操作。

本文将基于 MySQL，介绍数据库锁机制，相信大家耐心看了之后肯定有收获，码字不易，别忘了「在看」，「转发」哦。

锁的类型
MyISAM 锁机制
InnoDB 锁机制
正文
01 锁的类型
从对数据的操作粒度来划分，MySQL 大致可归纳为 3 种锁。

表级锁

表级别的锁定是 MySQL 各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是实现逻辑非常简单，带来的系统负面影响最小。

所以获取锁和释放锁的速度很快。由于表级锁一次会将整个表锁定，所以可以很好的避免困扰我们的死锁问题。

当然，锁定颗粒度大所带来最大的负面影响就是出现锁定资源争用的概率也会最高，致使并发大度大打折扣。

行级锁

行级锁定最大的特点就是锁定对象的颗粒度很小，也是目前各大数据库管理软件所实现的锁定颗粒度最小的。

由于锁定颗粒度很小，所以发生锁定资源争用的概率也最小，能够给予应用程序尽可能大的并发处理能力而提高一些需要高并发应用系统的整体性能。

虽然能够在并发处理能力上面有较大的优势，但是行级锁定也因此带来了不少弊端。由于锁定资源的颗粒度很小，所以每次获取锁和释放锁需要做的事情也更多，带来的消耗自然也就更大了。此外，行级锁定也最容易发生死锁。

页级锁

页面锁会去锁定一页的数据，我们知道 MySQL 的索引本身是由 B+ 树实现的。

每个叶子节点的单位页，叶子节点上面存放了多个记录行，数据存储是按照一页一页来的，每次锁定一页的数据，其实就是相邻的数据，开销和加锁时间界于表锁和行锁之间。

页级锁也会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

02 MyISAM锁机制
MyISAM引擎只提供表锁。

在执行查询语句（ SELECT ）前，会自动给涉及的表加读锁，此时允许其他用户对同一表的读操作。但会阻塞对同一个表的写操作。

在执行更新操作（ UPDATE、DELETE、INSERT 等）前，会自动给涉及的表加写锁，此时会阻塞其他用户对同一个表的读操作和写操作。

03 InnoDB锁机制
InnoDB 支持表锁、行锁，实际上InnoDB 是通过给索引项加锁，来实现行锁的。

只有查询数据时，检索条件走索引才可以使用行级锁，否则 InnoDB 将使用表锁。

在实际开发中，要特别注意 InnoDB 这一特性，不然，可能造成大量的锁冲突，从而影响并发！！！

InnoDB使用索引的条件

（1）在不通过索引条件查询的时候，InnoDB 确实使用的是表锁，而不是行锁。

（2）行锁是针对索引加锁，不是针对记录加的锁。即使访问的是不同行，但如果它们索引相同，还是会出现锁冲突。

（3）当表中含有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行。

（4）即使在条件中使用了索引，但是否使用索引来检索数据是由 MySQL 通过判断不同执行计划的代价决定的。如果 MySQL 认为全表扫描效率更高，比如很小的表，也不会使用索引，此时 InnoDB 将使用表锁，而不是行锁。因此，在分析锁冲突的时候，不要忘记检查 SQL 的执行计划，以确定是否真正使用了索引。

在默认的可重复读隔离级别下：

执行查询语句（ SELECT ）前，由于 MVCC（多版本控制）的方式，什么锁都不会加。

在执行更新操作（ UPDATE、DELETE、INSERT 等）前，会自动给涉及的行加写锁，此时会阻塞其他用户的写操作，但是通过 MVCC（多版本控制）的方式允许读操作。

04 总结
通过这篇文章，基于MySQL，为大家介绍了数据库的锁机制。针对不同情况，什么时候使用锁，锁到底生不生效是大家需要关注的问题。

原文链接：https://blog.csdn.net/kingcoding/java/article/details/107318680