概述

前言

锁是计算机协调多个进程或线程并发访问某一资源的机制。

在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。

分类

从对数据操作的类型分：

  • 读锁（共享锁）：针对同一份数据，多个读操作可以同时进行而不会相互影响。
  • 写锁（排他锁）：当前写操作没有完成之前，它会阻断其他写锁和读锁。

从对数据操作的粒度分：

  • 行级锁：对当前操作的行加锁。（开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度最高）
  • 表级锁：对当前操作的表加锁。（开销小，加锁快；不会出现死锁；锁定粒度大，发出锁冲突的概率最高，并发度最低）
  • 页级锁：介于行级锁和表级锁中间的一种锁。（开销和加锁时间介于表锁和行锁之间，会出现死锁；并发度一般）

事务

概述

事务是由一组SQL语句组成的逻辑处理单元，事务具有以下4个属性，通常简称为事务的ACID属性。

  • A(atomicity/原子性)：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。
  • C(consistency/一致性)：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。
  • I(isolation/隔离性)：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。
  • D(durability/持久性)：事务完成之后，它对于数据的修改是永久性的，即时出现系统故障也能够保持。

并发事务处理带来的问题

更新丢失（Lost Update）

当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题——最后的更新覆盖了由其他事务所做的更新。

例如，两个程序员修改同一Java文件。每程序员独立地更改其副本，然后保存更改的副本后，这样就覆盖了原始文档。最后保存其更改副本的编辑人员覆盖前一个程序员所做的更改。

如果一个在一个程序员完成并提交事务之前，另一个程序员不能访问同一文件，则可避免此问题。

脏读（Dirty Reads）

一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致状态；这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此做进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象地叫做“脏读”。

事务A读取到事务B已修改但未提交的数据，还在这个数据基础上做了操作。此时，如果B事务回滚，A读取的数据错误，不符合一致性。

不可重复读（Non-Repeatable Reads）

一个事务在服务某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或某些记录已经被删除，这种现象就叫做不可重复读。

在事务A的两次查询过程中间，事务B更新了原有数据，导致事务A的两次查询的数据不一致，不符合隔离性。

幻读（Phantom Reads）

一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。

在事务A的两次查询过程中间，事务B插入了新的数据，导致事务A的两次查询的数据数量不一致，不符合隔离性。

事务隔离级别

“脏读”、“不可重复读”和“幻读”，其实都是数据库读一致性问题，必须由数据库提供一定的书屋隔离级别来解决。

数据库实现事务隔离的方式，基本上可分为以下两种：

  • 一种是在读取数据前，对其加锁，阻止其他事物对数据修改。
  • 另一种是不用加任何锁，通过一定机制生成一个数据请求时间点的一致性数据快照（Snapshot），并用这个快照来提供一定级别（语句级或事务级）的一致性读取。同用户的角度来看，好像是数据库可以提供统一数据的多个版本，因此，这种技术叫数据多版本并发控制（MultiVersion Concurrency Control，简称MVCC或MCC），也经常称为多版本数据库。

为了解决“隔离”与“并发”的矛盾，ISO/ANSI SQL92定义了4个事务隔离级别，每个级别的隔离程度不同，允许出现的副作用也不同，允许出现的副作用也不同，应用可以根据自己的业务逻辑需求，通过选择不同的隔离级别来平衡“隔离”与“并发”的矛盾。

读数据一致性及允许的并发副作用隔离级别 读数据一致性 脏读 不可重复读 幻读
读取未提交（Read uncommitted） 最低级别 是 是 是
读取已提交（Read committed） 语句级 否 是 是
可重复读（Repeatable read） 事务级 否 否 是
可串行化（Serializable） 最高级别 否 否 否
  • Read_uncommited：最低的隔离级别，允许读取尚未提交的数据变更。（不能预防脏读、不可重复读、幻读）
  • Read_commited：允许读取并发事务已经提交的事务。（不能预防不可重复读、幻读）
  • Repeatable_read：对同一字段的多次读取结果都是一致的。（不能预防幻读）
  • Serializable：最高的隔离级别，完全服从ACID。所有事务依次逐个执行，这样事务之间就完全不可能产生干扰。

数据库的事务隔离越严格，并发副作用越小，但付出的代价也就越大，因为事务隔离实质上就是使事务在一定程度上“串行化”进行，这显然与“并发”是矛盾的。同时，不同的应用对读一致性和事务隔离程度的要求也是不同的，比如许多应用对“不可重复读”和“幻读”并不敏感，可能更关心数据并发访问的能力。

配置

查看的事务隔离级别（默认为可重复读）：SELECT @@transaction_isolation;

  1. mysql> SELECT @@transaction_isolation;
  2. +-------------------------+
  3. | @@transaction_isolation |
  4. +-------------------------+
  5. | REPEATABLE-READ         |
  6. +-------------------------+

设置读未提交: SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

设置读已提交：SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

设置可重复读：SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;

设置可序列化：SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

SQL命令

事务开始：BEGIN 或者 START TRANSACTION

事务结束：COMMIT或者COMMIT WORK

事务回滚：ROLLBACK或者ROLLBACK WORK

表锁

特点

表锁（偏读）：偏向MyISAM存储引擎，开销小，加锁快；无死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。

操作

手动增加表锁：LOCK TABLE <tablename_1> read(write),<tablename_1> read(write) ...

查看表上的锁：SHOW OPEN TABLES;

解锁：UNLOCK TABLES;

分析

分析表锁定：SHOW STATUS LIKE 'table%';

有两个状态变量记录MySQL内部表级锁定的情况，两个变量说下：

Table_locs_immediate：产生表级锁定的次数，表示可以立即获取锁的查询次数，每立即获取锁值+1;

Table_locks_waited：出现表级锁定争用而发生等待的次数（不能立即获取锁的次数，每等待一次锁值+1），此值高则说明存在着比较严重的表级锁争用情况。

此外，MyISAM的读写锁调度是写优先，这也是MyISAM不适合做写为主表的引擎，因为写锁后，其他线程不能做任何操作，大量的更新会使查询很难得到锁，从而造成永远阻塞。

总结

当前线程给一个表加上读锁时，当前线程和其他线程都可以读这个表，但是当前线程线程读其他表时会报错，当前线程写该表时会报错，其他线程写该表时会阻塞。

当前线程给一个表加上写锁时，当前线程可以对该表进行读和写操作，但是当前线程对其他表进行读和写操作时会报错，其他线程对该表进行读和写时会阻塞。

读锁阻塞写，写锁都阻塞。

行锁

特点

行锁（偏写）：偏向InnoDB存储引擎，开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。

InnoDB与MyISAM的最大不同有两点：一是支持事务；二是采用了行级锁。

InnoDB行锁实现方式

InnoDB行锁是通过索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件来检索数据，InnoDB才使用行级锁，否则InnoDB将使用表锁。

总结

当前线程begin以后对一张表进行写操作，其他线程对该表进行写操作时会阻塞。当前线程写操作完毕后仅当前线程可见，其他线程只能读更新之前的数据，只有当前线程commit;之后其他线程才可读更新数据。

间隙锁

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做间隙。

InnoDB也会对这个间隙加锁，这种锁机制就是所谓的间隙锁。

危害：因为Query执行过程中通过范围查找的话，它会锁定整个范围内的所有索引键值，即使这个键值并不存在。间隙所有一个比较致命的弱点，就是当锁定一个范围键值之后，即时某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害。

如何锁定一行

SELECT .....FOR UPDATE在锁定某一行后，其他写操作会被阻塞，直到锁定的行被COMMIT。

结论：

InnoDB存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些，但是在整体并发处理能力方面要远远优于MyISAM的表级锁定的。当系统并发量较高的时候，InnoDB的整体性能和MyISAM相比就会有比较明显的优势了。

但是，InnoDB的行级锁定同样有其脆弱的一面，当我们使用不当的时候，可能会让InnoDB的整体性能表现不仅不能比MyISAM高，甚至可能更差。

分析行锁定

通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况：SHOW STATUS LIKE 'innodb_row_lock;'

  1. mysql> SHOW STATUS LIKE 'innodb_row_lock%';
  2. +-------------------------------+-------+
  3. | Variable_name                 | Value |
  4. +-------------------------------+-------+
  5. | Innodb_row_lock_current_waits | 0     |
  6. | Innodb_row_lock_time          | 38921 |
  7. | Innodb_row_lock_time_avg      | 9730  |
  8. | Innodb_row_lock_time_max      | 14962 |
  9. | Innodb_row_lock_waits         | 4     |
  10. +-------------------------------+-------+

对各个状态量的说明如下：

  • Innodb_row_lock_current_waits：当前正在等待锁定的数量
  • Innodb_row_lock_time：从系统启动到现在锁定总时间长度
  • Innodb_row_lock_time_avg：每次等待所花平均时间
  • Innodb_row_lock_time_max：从系统启动到现在等待最长的一次所花的时间
  • Innodb_row_lock_waits：系统启动后到现在总共等待的次数

注意waits金额time_avg比较高的，就要分析系统并制定优化方案。

优化建议

  • 尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
  • 合理设计索引，尽量缩小锁的范围
  • 尽可能减少检索条件，避免间隙锁
  • 尽量控制事务大小，减少锁定资源量和时间长度
  • 尽可能低级别事务隔离

原理

保证一致性

从数据库层面，数据库通过原子性、隔离性、持久性来保证一致性。A(原子性)、I(隔离性)、D(持久性)是手段，是为了保证C(一致性)，数据库提供的手段。数据库必须要实现AID三大特性，才有可能保证一致性。
从应用层面，通过代码判断数据库数据是否有效，然后决定回滚还是提交数据。

保证原子性

利用InnoDB的undo log。

undo log：回滚日志，是实现原子性的关键，当事务回滚时能够撤销所有已经成功执行的SQL语句，它需要记录要回滚的相应日志信息。

  • 插入：记录数据主键，回滚时根据主键执行删除操作
  • 更新：记录之前旧值，回滚时根据旧值执行更新操作
  • 删除：记录这个数据，回滚时根据数据执行插入操作

保证持久性

利用InnoDB的redo log，分为两部分：redo log buffer和redo log file。

MySQL使用WAL技术（Write-Ahead Logging，预写式日志）。当数据更新的时候，先更新内存，并在redo log buffer中记录，并且写入到binlog中。
事务提交的时候，将事务日志从redo log buffer写入到磁盘的redo log file中进行持久化。

redo log的写入使用两阶段提交：prepare和commit，保证和binlog的逻辑一致。

保证隔离性

MVCC（Multiversion concurrency control ）是一种多版本并发控制机制。

  • 插入：添加隐藏两列，创建版本号(当前事务id)和删除版本号(null)
  • 查询：需要满足条件，创建版本号 < 当前事务id < 删除版本号
  • 删除：更新数据的删除版本号为当前事务id
  • 更新：复制一份数据，先执行删除，再执行插入，旧数据的删除版本号和新数据的创建版本号都设置为当前事务id

幻读

记录锁

单条索引记录上加锁，record lock锁住的永远是索引，而非记录本身，即使该表上没有任何索引，那么InnoDB会在后台创建一个隐藏的聚集主键索引，那么锁住的就是这个隐藏的聚集主键索引。
当一条SQL没有走任何索引时，那么将会在每一条聚集索引后面加锁，这个类似于表锁，但原理上和表锁是完全不同的。

间隙锁

在索引记录之间的间隙中加锁，或者是在某一条索引记录之前或者之后加锁，并不包括该索引记录本身。间隙锁的机制主要是解决可重复读模式下的幻读问题。

意向锁

InnoDB的意向锁主要用于多粒度的锁并存的情况，处理行锁和表锁之间的矛盾。

快照读

简单的select操作，没有lock in share mode或者for update，快照读不会加任何的锁，而且由于mysql的一致性非锁定读的机制存在，任何快照读也不会被阻塞。
但是如果事务隔离级别是Serializable的话，那么快照都也会被加上共享的next-key锁。

当前读

官方文档的术语叫locking read，也就是insert，update，delete，select in share mode和select for update，当前读会在所有扫描到的索引记录上加锁，不管它后面的where条件是否命中对应的行记录。
当前读可能会引起死锁。

next-key lock

在默认情况下，mysql的事务隔离级别是可重复读，并且innodb_locks_unsafe_foor_binlog参数为0，这时默认采用next-key lock。
所谓的nex-key lock，就是记录锁和间隙锁的结合，除了锁住记录本身，还要锁住索引之间的间隙。