开始MySQL之路——MySQL锁机制简单概述

朱雀 2024-03-26 22:29 76阅读 0赞

### MySql锁 ###

#### 锁的定义 ####

*  锁是⼀种⽤于保证在并发场景下每个事务仍能以⼀致性的⽅式读取和修改数据的⽅式，当⼀个事务对某⼀条数据上锁之后，其他事务就不能修改或者只能阻塞等待锁的释放，所以锁的粒度⼤⼩⼀定程度上可以影响到访问数据库的性能。

#### 锁的重要性 ####

*  在数据库中，除传统计算资源（CPU、RAM、I\\O等）的争抢，数据也是一种供多用户共享的资源。
 *  如何保证数据并发访问的一致性，有效性，是所有数据库必须要解决的问题。
 *  锁冲突也是影响数据库并发访问性能的一个重要因素，因此锁对数据库尤其重要。

#### 锁的缺点 ####

*  加锁是消耗资源的，锁的各种操作，包括获得锁、检测锁是否已解除、释放锁等 ，都会增加系统的开销。

#### 锁的分类 ####

**MySQL中有多种锁类型，包括乐观锁、悲观锁、全局锁、表级锁、页级锁、行级锁、共享锁、排它锁、意向共享锁、意向排它锁、间隙锁、临建锁和记录锁，下面分别介绍一下各种锁：**  
  
1. 乐观锁（Optimistic Locking）：假设并发操作时不会发生冲突，只在提交事务时检查数据是否被其他事务修改过。常用于读多写少的场景。  
  
2. 悲观锁（Pessimistic Locking）：假设并发操作时会发生冲突，因此在操作期间持有锁来避免冲突。常用于写多读少的场景。  
  
3. 全局锁（Global Lock）：对整个数据库实例加锁，限制除了超级用户外的所有查询和修改操作。一般用于备份、恢复等操作。  
  
4. 表级锁（Table Lock）：对整个表加锁，其他连接无法修改或读取该表的数据，但可以对其他表进行操作。  
  
5. 页级锁（Page Lock）：对数据页（通常是连续的几个行）加锁，控制并发事务对该页的访问。适用于数据较大且并发量较高的场景。  
  
6. 行级锁（Row Lock）：对单个行加锁，只锁定需要修改的数据行，其他行可以被同时修改或读取。并发性高，但锁管理较复杂。  
  
7. 共享锁（Shared Lock）：也称为读锁，多个事务可以同时持有共享锁并读取数据，但不能修改数据。适用于同时读取同一数据的场景。  
  
8. 排它锁（Exclusive Lock）：也称为写锁，事务持有排它锁时，其他事务无法同时持有共享锁或排它锁，用于保护数据的写操作。  
  
9. 意向共享锁（Intention Shared Lock）：表级锁的辅助锁，表示事务要在某个表或页级锁上获取共享锁。  
  
10. 意向排它锁（Intention Exclusive Lock）：表级锁的辅助锁，表示事务要在某个表或页级锁上获取排它锁。  
  
11. 间隙锁（Gap Lock）：锁定一个范围的键，但不包括这些键的实际值。用于防止其他事务在范围内插入数据。  
  
12. 临建锁（Metadata Lock）：锁定数据库对象的元数据，如表结构，用于保证数据定义的一致性。  
  
13. 记录锁（Record Lock）：行级锁的特定类型，锁定单个行，确保其他事务无法同时修改或读取该行。  
  
这些锁类型在不同的场景中可以组合使用，根据具体需求选择适当的锁策略来保证数据的一致性和并发性。同时，需要注意锁的粒度、锁冲突、死锁等问题，合理设计和管理锁可以提高数据库的并发性能。

### 死锁概念 ###

定义：当两个或以上的事务相互持有和请求锁，并形成一个循环的依赖关系，就会产生死锁。多个事务同时锁定同一个资源时，也会产生死锁。在一个事务系统中，死锁是确切存在并且是不能完全避免的。

#### 产生的条件 ####

1. 互斥条件：一个资源每次只能被一个进程使用  
2. 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放  
3. 不剥夺条件：进程已获得的资源，在没有使用完之前，不能强行剥夺  
4. 循环等待条件：多个进程之间形成的一种互相循环等待的资源的关系

#### 解决方法 ####

1. 查看死锁：show engine innodb status \\G  
2. 自动检测机制，超时自动回滚代价较小的事务（innodb\_lock\_wait\_timeout 默认50s）  
3. 人为解决，kill阻塞进程（show processlist）  
4. wait for graph 等待图（主动检测）

#### 避免方法 ####

在应用中，如果不同的程序会并发存取多个表，应尽量约定以相同的顺序来访问表，这样可以大大降低产生死锁的机会。在下面的例子中，由于两个session访问两个表的顺序不同，发生死锁的机会就非常高！但如果以相同的顺序来访问，死锁就可以避免。

在程序以批量方式处理数据的时候，如果事先对数据排序，保证每个线程按固定的顺序来处理记录，也可以大大降低出现死锁的可能。

在事务中，如果要更新记录，应该直接申请足够级别的锁，即排他锁，而不应先申请共享锁，更新时再申请排他锁，因为当用户申请排他锁时，其他事务可能又已经获得了相同记录的共享锁，从而造成锁冲突，甚至死锁。

在REPEATABLE-READ隔离级别下，如果两个线程同时对相同条件记录用SELECT...FOR UPDATE加排他锁，在没有符合该条件记录情况下，两个线程都会加锁成功。程序发现记录尚不存在，就试图插入一条新记录，如果两个线程都这么做，就会出现死锁。这种情况下，将隔离级别改成READ COMMITTED，就可避免问题。

当隔离级别为READ COMMITTED时，如果两个线程都先执行SELECT...FOR UPDATE，判断是否存在符合条件的记录，如果没有，就插入记录。此时，只有一个线程能插入成功，另一个线程会出现锁等待，当第1个线程提交后，第2个线程会因主键重出错，但虽然这个线程出错了，却会获得一个排他锁！这时如果有第3个线程又来申请排他锁，也会出现死锁。

对于这种情况，可以直接做插入操作，然后再捕获主键重异常，或者在遇到主键重错误时，总是执行ROLLBACK释放获得的排他锁