MySQL 之锁机制

表锁 ( 偏读 )

特点

• 偏向 MyISAM 存储引擎，开销小，加锁快，无死锁
• 锁定粒度大，发生锁冲突的概率最高，并发度最低

操作

手动增加表锁

LOCK TABLE 表1 READ ( WRITE )，表2 READ (WRITE);

查看表上加过的锁

SHOW OPEN TABLES;

释放表锁

UNLOCK TABLES;

结论

• MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行增删改操作前，会自动给涉及的表加写锁
• MySQL的表级锁有两种模式
  • 表共享读锁（Table Read Lock）
  • 表独占写锁（Table Write Lock）
• 占有读锁的会话不能查询其他表，也无法插入或更新表（包括被锁的表），直到释放锁，其他会话可以查询或者更新未锁定的表，插入或者更新锁定的表会一直等待直到获得锁
• 占用写锁的会话可以对锁定表进行查询，更新和插入操作，其他会话对锁定表的查询被阻塞，需要等待锁被释放
• 对 MyISAM 表的读操作，不会阻塞其他进程对同一表的读请求，但会阻塞对同一表的写请求，只有当读锁释放后，才会执行其它进程的写操作
• 对 MyISAM 表的写操作，会阻塞其他进程对同一表的读和写操作，只有当写锁释放后，才会执行其它进程的读写操作
• 简而言之，就是读锁会阻塞写，但是不会堵塞读，而写锁则会把读和写都堵塞

行锁(偏写)

• 偏向 InnoDB 存储引擎，开销大，加锁慢
• 会出现死锁
• 锁定粒度最小，发生锁冲突的概率最低，并发度也最高
• InnoDB 与 MyISAM 的最大不同有两点
  • 一是支持事务（TRANSACTION）
  • 二是采用了行级锁

如何分析行锁定

通过检查 InnoDB_row_lock 状态变量来分析系统上的行锁的争夺情况

show status like 'innodb_row_lock%'

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

查询正在被锁阻塞的 SQL 语句

SELECT * FROM information_schema.INNODB_TRX

MySQL 事务

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

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

事务带来的问题

并发一致性问题

丢失修改（Lost Update）

丢失修改指一个事务的更新操作被另外一个事务的更新操作替换。一般在现实生活中常会遇到，例如：T1 和 T2 两个事务都对一个数据进行修改，T1 先修改并提交生效，T2 随后修改，T2 的修改覆盖了 T1 的修改

读脏数据（Dirty Reads）

读脏数据指在不同的事务下，当前事务可以读到另外事务未提交的数据，例如：T1 修改一个数据但未提交，T2 随后读取这个数据。如果 T1 撤销了这次修改，那么 T2 读取的数据是脏数据

不可重复读（Non-Repeatable Reads）

不可重复读指在一个事务内多次读取同一数据集合。在这一事务还未结束前，另一事务也访问了该同一数据集合并做了修改，由于第二个事务的修改，第一次事务的两次读取的数据可能不一致，例如：T2 读取一个数据，T1 对该数据做了修改。如果 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不同

幻影读（Phantom Reads）

幻读本质上也属于不可重复读的情况，T1 读取某个范围的数据，T2 在这个范围内插入新的数据，T1 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同

隔离级别

未提交读（READ UNCOMMITTED）

事务中的修改，即使没有提交，对其它事务也是可见的

提交读（READ COMMITTED）

一个事务只能读取已经提交的事务所做的修改。换句话说，一个事务所做的修改在提交之前对其它事务是不可见的

可重复读（REPEATABLE READ）

保证在同一个事务中多次读取同一数据的结果是一样的。

可串行化（SERIALIZABLE）

强制事务串行执行，这样多个事务互不干扰，不会出现并发一致性问题

该隔离级别需要加锁实现，因为要使用加锁机制保证同一时间只有一个事务执行，也就是保证事务串行执行

加读锁（共享锁）

共享锁又称读锁，是读取操作创建的锁，其他用户可以并发读取数据，但任何事务都不能对数据进行修改（ 获取数据上的排他锁 ），直到已释放所有共享锁

如果事务 T 对数据 A 加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁，获准共享锁的事务只能读数据，不能修改数据

语法

SELECT ... LOCK IN SHARE MODE;

在查询语句后面增加 LOCK IN SHARE MODE ，MySQL 会对查询结果中的每行都加共享锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请共享锁，否则会被阻塞，其他线程也可以读取使用了共享锁的行，而且这些线程读取的是同一个版本的数据

写锁（排他锁）

共享锁又称写锁，如果事务T对数据A加上排他锁后，则其他事务不能再对A加任任何类型的封锁。获准排他锁的事务既能读数据，又能修改数据

SELECT ... FOR UPDATE;

在查询语句后面增加 FOR UPDATE ，MySQL 会对查询结果中的每行都加排他锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请排他锁，否则会被阻塞

间隙锁

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB 会给符合条件的已有数据记录的索引项加锁，对于键值在条件范围内但并不存在的记录，叫做 “间隙（GAP)”，InnoDB 也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（GAP Lock）

危害

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

结论

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

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

• 没有索引会导致行锁升级为表锁

优化建议

• 尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
• 尽可能较少检索条件，避免间隙锁
• 尽量控制事务大小，减少锁定资源量和时间长度
• 锁住某行后，尽量不要去调别的行或表，赶紧处理被锁住的行然后释放掉锁
• 涉及相同表的事务，对于调用表的顺序尽量保持一致
• 在业务环境允许的情况下,尽可能低级别事务隔离

页锁

开销和加锁时间界于表锁和行锁之间，会出现死锁，锁定粒度界于表锁和行锁之间，并发度一般