Mysql中的锁机制

一、前言

锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的 计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一 个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。本章我们着重讨论MySQL锁机制 的特点，常见的锁问题，以及解决MySQL锁问题的一些方法或建议。
Mysql用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。这些锁统称为悲观锁(Pessimistic Lock)。

二、MySQL锁概述

相对其他数据库而言，MySQL的锁机制比较简单，其最 显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。

• 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
• 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
• 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

从上述特点可见，很难笼统地说哪种锁更好，只能就具体应用的特点来说哪种锁更合适！仅从锁的角度 来说：表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有 并发查询的应用，如一些在线事务处理（OLTP）系统。

三、mysql 锁分类

3.1按属性分：

a. 共享锁(读锁) S：当一个事务对数据添加读锁后，其他事务只能对该数据加读锁，不能做修改操作，也就是加写锁。
b. 排他锁(写锁) X：当一个事务对数据添加写锁后，其他事务既不能对该数据加读锁，也不能加写锁。只有等待当前写锁释放后，才能进行后续加锁操作。

3.2 按状态分：

• 意向共享锁 IS：事务有意向对表中的某些行加共享锁。事务在获得某些行的共享锁之前，要先获得表的意向共享锁。
• 意向排他锁 IX：事务有意向对表中的某些行加排他锁。事务在获得某些行的排他锁之前，要先获得表的意向排他锁。

意向锁的存在是为了协调行锁和表锁的关系，支持多粒度（表锁与行锁）的锁并存。意向锁是表锁，不会与行级的共享锁、排他锁互斥，与表级的共享锁、排他锁兼容关系如下：

3.3按粒度分：

• 全局锁： 对整个数据库实例加锁，让整个库处于只读状态，命令是Flush tables with read lock (FTWRL)，通常用于数据备份。
• 表锁：表锁分为表锁和元数据锁(MDL)

表锁：加锁语句lock tables t1 read, t2 write; 可以用 unlock tables 主动释放锁。
元数据锁（metadata lock）：MDL不需要显示使用，在访问表时自动加上，最主要的目的是防止DDL与DML并发冲突。
需要注意的是DML读锁保证的是表结构不能修改，与表数据无关，可以对数据进行操作，与读锁有区别。MDL写锁保证的是表结构不能修改，并且数据也不能读取。

• 页锁：页级锁是 MySQL 中锁定粒度介于行级锁和表级锁中间的一种锁。目前只有BDB引擎支持页级锁。

• 行锁：行锁是粒度最小、发生锁冲突概率最低、并发度最高的锁，但是加锁慢、开销大，容易发生死锁现象。目前只有innodb引擎支持行锁，行锁通过锁索引来实现，当无法通过索引来加锁时，行锁会转成表锁。

记录锁、间隙锁和临键锁都属于行锁。

3.4按模式分：

• 乐观锁：乐观锁假设数据不会发生冲突，只有在数据提交更新时才会检测是否冲突，如果冲突了才会返回错误信息。适用于读多写少的场景。

• 悲观锁：悲观锁具有强烈的独占和排他特性，适用于并发量不大、写入比较频繁、数据一致性比较高的场景。Mysql中的共享锁和排他锁都属于悲观锁。

3.5按算法分

• 记录锁：精准命中唯一索引或主键索引时加记录锁，避免不可重复读和脏读问题。

• 间隙锁：普通索引、联合索引命中，或者唯一索引命中多行数据时加锁，避免幻读问题。

• 临键锁：记录锁和间隙锁的组合，索引命中多行数据时加锁，避免脏读、幻读和不可重复读三个问题。

四.InnoDB锁

InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁。行级锁与表级锁本来就有许多不同之处，另外，事务的引入也带来了一些新问题。现在主流用的就是InnoDB引擎。

4.1事务（Transaction）及其ACID属性

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

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

4.2并发事务带来的问题

相对于串行处理来说，并发事务处理能大大增加数据库资源的利用率，提高数据库系统的事务吞吐量，从而可以支持可以支持更多的用户。但并发事务处理也会带来一些问题，主要包括以下几种情况。

• 更新丢失（Lost Update）：当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题——最后的更新覆盖了其他事务所做的更新。例如，两个编辑人员制作了同一文档的电子副本。每个编辑人员独立地更改其副本，然后保存更改后的副本，这样就覆盖了原始文档。最后保存其更改保存其更改副本的编辑人员覆盖另一个编辑人员所做的修改。如果在一个编辑人员完成并提交事务之前，另一个编辑人员不能访问同一文件，则可避免此问题。
• 脏读（Dirty Reads）：一个事务在处理过程中读取了另外一个事务未提交的数据。
• 不可重复读（Non-Repeatable Reads）：同一事务内两次读取数据，获得的内容不一样，或因更新、删除导致的两次读取记录数不一致。
• 幻读（Phantom Reads）： 同一事务内两次读取数据，记录数不一样(专指新插入行导致的记录数不一致，更新、删除导致的记录数不一致属于不可重复读的一种)。

4.3事务隔离级别

在并发事务处理带来的问题中，“更新丢失”通常应该是完全避免的。但防止更新丢失，并不能单靠数据库事务控制器来解决，需要应用程序对要更新的数据加必要的锁来解决，因此，防止更新丢失应该是应用的责任。

“脏读”、“不可重复读”和“幻读”，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。数据库实现事务隔离的方式，基本可以分为以下两种。

• 一种是在读取数据前，对其加锁，阻止其他事务对数据进行修改。目前已不需要特殊处理，MYSQL自动实现
• 另一种是不用加任何锁，通过一定机制生成一个数据请求时间点的一致性数据快照（Snapshot），并用这个快照来提供一定级别（语句级或事务级）的一致性读取。从用户的角度，好像是数据库可以提供同一数据的多个版本，因此，这种技术叫做数据多版本并发控制（ＭultiVersion Concurrency Control，简称MVCC或MCC），也经常称为多版本数据库。

在MVCC并发控制中，读操作可以分成两类：快照读 (snapshot read)与当前读 (current read)。快照读，读取的是记录的可见版本 (有可能是历史版本)，不用加锁。当前读，读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。
在一个支持MVCC并发控制的系统中，哪些读操作是快照读？哪些操作又是当前读呢？以MySQL InnoDB为例：

快照读：简单的select操作，属于快照读，不加锁。(当然，也有例外)
当前读：特殊的读操作，插入/更新/删除操作，属于当前读，需要加锁。

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

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

mysql设置已提交读解决赃读，MVCC解决幻读和快照度问题，不需要额外加锁处理并发问题，执行SQL时自动增加间隙锁、行锁；java通过redis和zk加锁解决并发事务问题。

但是，也并不是所有的一连串操作都弄成同一个事务，所以出现了脏读、幻读可以考虑其他问题，比如数据库主从同步的会话一致性，设置合理的同步机制可以解决

五、小结

在了解InnoDB锁特性后，用户可以通过设计和SQL调整等措施减少锁冲突和死锁，包括：

• 尽量使用较低的隔离级别； 精心设计索引，并尽量使用索引访问数据，使加锁更精确，从而减少锁冲突的机会；
• 选择合理的事务大小，小事务发生锁冲突的几率也更小；
• 给记录集显式加锁时，最好一次性请求足够级别的锁。比如要修改数据的话，最好直接申请排他锁，而不是先申请共享锁，修改时再请求排他锁，这样容易产生死锁；
• 不同的程序访问一组表时，应尽量约定以相同的顺序访问各表，对一个表而言，尽可能以固定的顺序存取表中的行。这样可以大大减少死锁的机会；
• 尽量用相等条件访问数据，这样可以避免间隙锁对并发插入的影响； 不要申请超过实际需要的锁级别；除非必须，查询时不要显示加锁；
• 对于一些特定的事务，可以使用表锁来提高处理速度或减少死锁的可能。

如有不对，请指正