【免费】MySQL加锁处理分析@何登成1

需积分: 0 66 浏览量 2022-08-08 22:49:16 上传评论收藏 956KB DOCX 举报

资源详情

资源评论

资源推荐

1 背景 1

1.1 MVCC：Snapshot Read vs Current Read 2

1.2 Cluster Index：聚簇索引 3

1.3 2PL：Two-Phase Locking 3

1.4 Isolation Level 4

2 一条简单 SQL 的加锁实现分析 5

2.1 组合一：id 主键+RC 6

2.2 组合二：id 唯一索引+RC 6

2.3 组合三：id 非唯一索引+RC 7

2.4 组合四：id 无索引+RC 8

2.5 组合五：id 主键+RR 9

2.6 组合六：id 唯一索引+RR 9

2.7 组合七：id 非唯一索引+RR 9

2.8 组合八：id 无索引+RR 11

2.9 组合九：Serializable 12

3 一条复杂的 SQL 12

4 死锁原理与分析 14

5 总结 16

1. 背景

MySQL/InnoDB 的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事

咨询这方面的问题。同时，微博上也经常会收到 MySQL 锁相关的私信，让我帮助解决一些

死锁的问题。本文，准备就 MySQL/InnoDB 的加锁问题，展开较为深入的分析与讨论，主要

是介绍一种思路，运用此思路，拿到任何一条 SQL 语句，都能完整的分析出这条语句会加

什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。

注：MySQL 是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于

InnoDB 存储引擎，其他引擎的表现，会有较大的区别。

1. MVCC：Snapshot Read vs Current Read

MySQL InnoDB 存储引擎，实现的是基于多版本的并发控制协议——MVCC (Multi-Version

Concurrency Control) (注：与 MVCC 相对的，是基于锁的并发控制，Lock-Based Concurrency

Control)。MVCC 最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的 OLTP

应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，

几乎所有的 RDBMS，都支持了 MVCC。

在 MVCC 并发控制中，读操作可以分成两类：快照读 (snapshot read)与当前读 (current

read)。快照读，读取的是记录的可见版本 (有可能是历史版本)，不用加锁。当前读，读取

的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修

改这条记录。

在一个支持 MVCC 并发控制的系统中，哪些读操作是快照读？哪些操作又是当前读呢？以

1. Isolation Level

隔离级别：Isolation Level，也是 RDBMS 的一个关键特性。相信对数据库有所了解的朋友，

对于 4 种隔离级别：Read Uncommited，Read Committed，Repeatable Read，Serializable，都

有了深入的认识。本文不打算讨论数据库理论中，是如何定义这 4 种隔离级别的含义的，而

是跟大家介绍一下 MySQL/InnoDB 是如何定义这 4 种隔离级别的。

MySQL/InnoDB 定义的 4 种隔离级别：

� Read Uncommited

可以读取未提交记录。此隔离级别，不会使用，忽略。

� Read Committed (RC)

快照读忽略，本文不考虑。

针对当前读，RC 隔离级别保证对读取到的记录加锁 (记录锁)，存在幻读现象。

� Repeatable Read (RR)

快照读忽略，本文不考虑。

针对当前读，RR 隔离级别保证对读取到的记录加锁 (记录锁)，同时保证对读取的范围加锁，

新的满足查询条件的记录不能够插入 (间隙锁)，不存在幻读现象。

� Serializable

从 MVCC 并发控制退化为基于锁的并发控制。不区别快照读与当前读，所有的读操作均为当

前读，读加读锁 (S 锁)，写加写锁 (X 锁)。

Serializable 隔离级别下，读写冲突，因此并发度急剧下降，在 MySQL/InnoDB 下不建议使用。

1. 一条简单 SQL 的加锁实现分析

在介绍完一些背景知识之后，本文接下来将选择几个有代表性的例子，来详细分析 MySQL

的加锁处理。当然，还是从最简单的例子说起。经常有朋友发给我一个 SQL，然后问我，这

个 SQL 加什么锁？就如同下面两条简单的 SQL，他们加什么锁？

� SQL1：select * from t1 where id = 10;

� SQL2：delete from t1 where id = 10;

针对这个问题，该怎么回答？我能想象到的一个答案是：

� SQL1：不加锁。因为 MySQL 是使用多版本并发控制的，读不加锁。

� SQL2：对 id = 10 的记录加写锁 (走主键索引)。

这个答案对吗？说不上来。即可能是正确的，也有可能是错误的，已知条件不足，这个问题

没有答案。如果让我来回答这个问题，我必须还要知道以下的一些前提，前提不同，我能给

出的答案也就不同。要回答这个问题，还缺少哪些前提条件？

� 前提一：id 列是不是主键？

� 前提二：当前系统的隔离级别是什么？

剩余16页未读，继续阅读

评论收藏

内容反馈

白小俗

粉丝: 30
资源: 303

MySQL加锁处理分析@何登成1

评论0

最新资源

MySQL加锁处理分析@何登成1

评论0

MySQL 加锁处理分析

阿里大牛何sir 深入MySQL加锁处理分析

何登成 - 管中窥豹——MySQL(InnoDB)死锁分析之道

MySQL查询优化浅析-何登成大师作品

数据库系统化实战（MySQL）-丁奇

MySQL 主从原理、问题、解决方案和应用-淘宝大牛丁奇

MySQL 加锁处理分析1

何登成的技术博客 » MySQL 加锁处理分析1

MySQL语句加锁的实现分析

MySQL的并发控制与加锁分析1

mysql加锁分析

mysql加锁分析_v1

MySQL DELETE 删除语句加锁分析1

4.5 mysql 加锁分析.pdf

Java高级试听课：MySQL 执行计划查看、索引失效分析、加锁分析.txt

MySQL中update操作会自动加锁吗

PHP+MySQL高并发加锁事务处理问题解决方法

解决Mysql Error-The user specified as a definer (‘mysql.infoschema’

MySQL中InnoDB存储引擎的加锁分析

MySQL的死锁系列- 锁的类型以及加锁原理

mysql insert 加锁流程1

最新版ISO/IEC 27001:2022、ISO 27002:2022中英文合集

Goby红队版-win-x64-2.4.7版本

Chrome Header Editor 插件

ISO SAE 21434-2021 中文版.pdf

安全认证cisp教材全套

OpenVAS GVM 中文翻译补丁

最新资源