产品中心
在数据库中设计锁的目的是为了处理并发问题，在并发对资源进行访问时，数据库要合理控制对资源的访问规则。
而锁就是用来实现这些访问规则的一个数据结构。
在对数据并发操作时，没有锁可能会引起数据的不一致，导致更新丢失。
乐观锁： 对于出现更新丢失的可能性比较乐观，先认为不会出现更新丢失，在最后更新数据时进行比较。
MDL读锁之间不互斥，因为一张表可以支持多个事务同时增删改查，读锁和写锁、写锁和写锁之间互斥，用来保证对表结构变更的安全性。
在对表执行DDL时，会导致所有的增删改查阻塞。所以在对表字段进行修改或增加字段时，一定要特别小心。
一般我们在对大数据量表做DDL时都会格外注意，以免对线上业务造成影响。但是对小表做DDL操作时同样要小心，比如以下场景：
事务A先启动，这时会对表t加一个MDL读锁；
然后事务B要对表t增加字段，这是需要获取一个MDL写锁，但是由于这时事务A还没有提交，所以MDL读锁没有释放，所以事务B会被阻塞；
如果仅仅是事务B阻塞倒也没什么关系，顶多是DDL晚点执行；但是在这之后的所有对表t的增删改查都会被阻塞，导致表t不能执行任何读写操作。
意向锁是加在表级别的一个锁，分为意向共享锁（IS锁）和意向排它锁（IX锁）。
意向锁，顾名思义，就是指明接下来要做的是一个什么类型的操作。
意向共享锁（IS）：在准备给表数据添加一个S锁时，需要先获得该表的IS锁。
意向排他锁（IX）：在准备给表数据添加一个X锁时，需要先获得该表的IX锁。
之所以有意向锁的存在，所以在上面的例子中：
意向锁的出现还有一个主要原因是为了在支持不同粒度锁时，能有更高的效率。
事务A对表T中的某一数据行添加了行锁，这时事务B要对表T添加表锁，但是在添加之前需要先检查是否有其他事务持有该表的X锁，如果持有则要阻塞；
事务B通过遍历表T中的所有行是否有锁，这样判断效率很低，非常耗时。
而意向锁因为是表级别的锁，在事务A在更新数据添加行锁之前，会在表级别由数据库自动添加一个IX锁，那么当事务B在需要获取X锁时，只需要检查表级别是否有IX锁，如果有IX锁代表当前有其他事务正在对表或者表中数据执行写操作，不能加锁成功。
MySQL中的行锁是在存储引擎层实现的，并不是所有的存储引擎都支持，比如MyISAM引擎中就没有行锁。
行锁顾名思义，是在数据行上添加锁，比如事务A要更新一行数据，先添加了行锁，然后事务B也要更新该行数据，则必须等事务A释放行锁之后才能更新。
行锁的加锁和解锁时机
在InnoDB事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。
我们都知道每个技术的出现都是为了解决某个问题，那么间隙锁又是为了解决什么问题呢？
假设没有间隙锁，会怎么样，我们来看下面的例子，以下内容都是在可重复读隔离级别的前提下。
有如下一张表：
在事务A中执行了3次查询，都是通过for update获取写锁，并且是当前读。
假设只有id=5这一行加锁，那么三个查询的执行结果如下：
那么Q3的结果中查询到id=1的数据，这个现象被称为“幻读”。
这破坏了事务A中select * from t where d=5 fot update;要把所有d=5的数据锁住的语义。
其次，会存在数据一致性问题。
如果在事务B中将binlog拿到备库执行会得到不一样的结果。
实际验证一下，得到结果并不是只对id=5这一行加锁，并且对所有的间隙也加了锁。这样就保证不能再插入新的数据。
间隙锁和行锁合称next-key lock，每个next-key lock是前开后闭区间。也就是说，我们的表t初始化以后，如果用select * from t where for update要把整个表所有记录锁起来，就形成了7个next-key lock，分别是 (-∞,0]、(0,5]、(5,10]、(10,15]、(15,20]、(20, 25]、(25, +supremum]。
间隙锁和临建锁的目的都是用来解决可重复读的问题，如果在读提交级别，间隙锁和临建锁都会失效。
MySQL中数据加锁的规则可以归纳为以下三种：
两个原则
两个优化
一个BUG
什么是死锁？
在支持并发操作的系统中，不同的线程对资源出现循环依赖，线程之间互相持有对方需要的资源，导致线程都进入无限等待的状态，称之为死锁。
而在数据库中因为有锁机制的存在，同样会导致死锁。比如：
当出现死锁后，有两种处理策略：
innodb_lock_wait_timeout设置。innodb_deadlock_detect设置为on，表示开启死锁检测。到此这篇关于一篇文章搞懂MySQL加锁机制的文章就介绍到这了,更多相关MySQL加锁机制内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
