xinyin025/learn.lianglianglee.com
1
0
Fork 0
mirror of https://github.com/zhwei820/learn.lianglianglee.com.git synced 2025-09-25 12:46:41 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity
387f48277a
learn.lianglianglee.com/专栏/MySQL实战45讲/30 答疑文章（二）：用动态的观点看加锁.md.html
周伟 387f48277a u
2022-05-11 18:46:27 +08:00

1281 lines
33 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<!-- saved from url=(0046)https://kaiiiz.github.io/hexo-theme-book-demo/ -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0, user-scalable=no">
<link rel="icon" href="/static/favicon.png">
<title>30 答疑文章（二）：用动态的观点看加锁.md</title>
<!-- Spectre.css framework -->
<link rel="stylesheet" href="/static/index.css">
<!-- theme css & js -->
<meta name="generator" content="Hexo 4.2.0">
</head>
<body>
<div class="book-container">
<div class="book-sidebar">
<div class="book-brand">
<a href="/">
<img src="/static/favicon.png">
<span>技术文章摘抄</span>
</a>
</div>
<div class="book-menu uncollapsible">
<ul class="uncollapsible">
<li><a href="/" class="current-tab">首页</a></li>
</ul>
<ul class="uncollapsible">
<li><a href="../">上一级</a></li>
</ul>
<ul class="uncollapsible">
<li>
<a href="/专栏/MySQL实战45讲/00 开篇词 这一次，让我们一起来搞懂MySQL.md">00 开篇词 这一次，让我们一起来搞懂MySQL.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/01 基础架构：一条SQL查询语句是如何执行的？.md">01 基础架构：一条SQL查询语句是如何执行的？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/02 日志系统：一条SQL更新语句是如何执行的？.md">02 日志系统：一条SQL更新语句是如何执行的？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/03 事务隔离：为什么你改了我还看不见？.md">03 事务隔离：为什么你改了我还看不见？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/04 深入浅出索引（上）.md">04 深入浅出索引（上）.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/05 深入浅出索引（下）.md">05 深入浅出索引（下）.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/06 全局锁和表锁 ：给表加个字段怎么有这么多阻碍？.md">06 全局锁和表锁 ：给表加个字段怎么有这么多阻碍？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/07 行锁功过：怎么减少行锁对性能的影响？.md">07 行锁功过：怎么减少行锁对性能的影响？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/08 事务到底是隔离的还是不隔离的？.md">08 事务到底是隔离的还是不隔离的？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/09 普通索引和唯一索引，应该怎么选择？.md">09 普通索引和唯一索引，应该怎么选择？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/10 MySQL为什么有时候会选错索引？.md">10 MySQL为什么有时候会选错索引？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/11 怎么给字符串字段加索引？.md">11 怎么给字符串字段加索引？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/12 为什么我的MySQL会“抖”一下？.md">12 为什么我的MySQL会“抖”一下？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/13 为什么表数据删掉一半，表文件大小不变？.md">13 为什么表数据删掉一半，表文件大小不变？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/14 count()这么慢，我该怎么办？.md">14 count()这么慢，我该怎么办？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/15 答疑文章（一）：日志和索引相关问题.md">15 答疑文章（一）：日志和索引相关问题.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/16 “order by”是怎么工作的？.md">16 “order by”是怎么工作的？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/17 如何正确地显示随机消息？.md">17 如何正确地显示随机消息？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/18 为什么这些SQL语句逻辑相同，性能却差异巨大？.md">18 为什么这些SQL语句逻辑相同，性能却差异巨大？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/19 为什么我只查一行的语句，也执行这么慢？.md">19 为什么我只查一行的语句，也执行这么慢？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/20 幻读是什么，幻读有什么问题？.md">20 幻读是什么，幻读有什么问题？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/21 为什么我只改一行的语句，锁这么多？.md">21 为什么我只改一行的语句，锁这么多？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/22 MySQL有哪些“饮鸩止渴”提高性能的方法？.md">22 MySQL有哪些“饮鸩止渴”提高性能的方法？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/23 MySQL是怎么保证数据不丢的？.md">23 MySQL是怎么保证数据不丢的？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/24 MySQL是怎么保证主备一致的？.md">24 MySQL是怎么保证主备一致的？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/25 MySQL是怎么保证高可用的？.md">25 MySQL是怎么保证高可用的？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/26 备库为什么会延迟好几个小时？.md">26 备库为什么会延迟好几个小时？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/27 主库出问题了，从库怎么办？.md">27 主库出问题了，从库怎么办？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/28 读写分离有哪些坑？.md">28 读写分离有哪些坑？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/29 如何判断一个数据库是不是出问题了？.md">29 如何判断一个数据库是不是出问题了？.md.html</a>
</li>
<li>
<a class="current-tab" href="/专栏/MySQL实战45讲/30 答疑文章（二）：用动态的观点看加锁.md">30 答疑文章（二）：用动态的观点看加锁.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/31 误删数据后除了跑路，还能怎么办？.md">31 误删数据后除了跑路，还能怎么办？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/32 为什么还有kill不掉的语句？.md">32 为什么还有kill不掉的语句？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/33 我查这么多数据，会不会把数据库内存打爆？.md">33 我查这么多数据，会不会把数据库内存打爆？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/34 到底可不可以使用join？.md">34 到底可不可以使用join？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/35 join语句怎么优化？.md">35 join语句怎么优化？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/36 为什么临时表可以重名？.md">36 为什么临时表可以重名？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/37 什么时候会使用内部临时表？.md">37 什么时候会使用内部临时表？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/38 都说InnoDB好，那还要不要使用Memory引擎？.md">38 都说InnoDB好，那还要不要使用Memory引擎？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/39 自增主键为什么不是连续的？.md">39 自增主键为什么不是连续的？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/40 insert语句的锁为什么这么多？.md">40 insert语句的锁为什么这么多？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/41 怎么最快地复制一张表？.md">41 怎么最快地复制一张表？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/42 grant之后要跟着flush privileges吗？.md">42 grant之后要跟着flush privileges吗？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/43 要不要使用分区表？.md">43 要不要使用分区表？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/44 答疑文章（三）：说一说这些好问题.md">44 答疑文章（三）：说一说这些好问题.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/45 自增id用完怎么办？.md">45 自增id用完怎么办？.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/我的MySQL心路历程.md">我的MySQL心路历程.md.html</a>
</li>
<li>
<a href="/专栏/MySQL实战45讲/结束语 点线网面，一起构建MySQL知识网络.md">结束语 点线网面，一起构建MySQL知识网络.md.html</a>
</li>
</ul>
</div>
</div>
<div class="sidebar-toggle" onclick="sidebar_toggle()" onmouseover="add_inner()" onmouseleave="remove_inner()">
<div class="sidebar-toggle-inner"></div>
</div>
<script>
function add_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
inner.classList.add('show')
}
function remove_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
inner.classList.remove('show')
}
function sidebar_toggle() {
let sidebar_toggle = document.querySelector('.sidebar-toggle')
let sidebar = document.querySelector('.book-sidebar')
let content = document.querySelector('.off-canvas-content')
if (sidebar_toggle.classList.contains('extend')) { // show
sidebar_toggle.classList.remove('extend')
sidebar.classList.remove('hide')
content.classList.remove('extend')
} else { // hide
sidebar_toggle.classList.add('extend')
sidebar.classList.add('hide')
content.classList.add('extend')
}
}
function open_sidebar() {
let sidebar = document.querySelector('.book-sidebar')
let overlay = document.querySelector('.off-canvas-overlay')
sidebar.classList.add('show')
overlay.classList.add('show')
}
function hide_canvas() {
let sidebar = document.querySelector('.book-sidebar')
let overlay = document.querySelector('.off-canvas-overlay')
sidebar.classList.remove('show')
overlay.classList.remove('show')
}
</script>
<div class="off-canvas-content">
<div class="columns">
<div class="column col-12 col-lg-12">
<div class="book-navbar">
<!-- For Responsive Layout -->
<header class="navbar">
<section class="navbar-section">
<a onclick="open_sidebar()">
<i class="icon icon-menu"></i>
</a>
</section>
</header>
</div>
<div class="book-content" style="max-width: 960px; margin: 0 auto;
overflow-x: auto;
overflow-y: hidden;">
<div class="book-post">
<p id="tip" align="center"></p>
<div><h1>30 答疑文章（二）：用动态的观点看加锁</h1>
<p>在第[20]和[21]篇文章中，我和你介绍了 InnoDB 的间隙锁、next-key lock，以及加锁规则。在这两篇文章的评论区，出现了很多高质量的留言。我觉得通过分析这些问题，可以帮助你加深对加锁规则的理解。</p>
<p>所以，我就从中挑选了几个有代表性的问题，构成了今天这篇答疑文章的主题，即：用动态的观点看加锁。</p>
<p><strong>为了方便你理解，我们再一起复习一下加锁规则。这个规则中，包含了两个“原则”、两个“优化”和一个“bug”：</strong></p>
<ul>
<li>原则 1：加锁的基本单位是 next-key lock。希望你还记得，next-key lock 是前开后闭区间。</li>
<li>原则 2：查找过程中访问到的对象才会加锁。</li>
<li>优化 1：索引上的等值查询，给唯一索引加锁的时候，next-key lock 退化为行锁。</li>
<li>优化 2：索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，next-key lock 退化为间隙锁。</li>
<li>一个 bug：唯一索引上的范围查询会访问到不满足条件的第一个值为止。</li>
</ul>
<p>接下来，我们的讨论还是基于下面这个表 t：</p>
<pre><code>CREATE TABLE `t` (
`id` int(11) NOT NULL,
`c` int(11) DEFAULT NULL,
`d` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `c` (`c`)
) ENGINE=InnoDB;
insert into t values(0,0,0),(5,5,5),
(10,10,10),(15,15,15),(20,20,20),(25,25,25);
</code></pre>
<h1>不等号条件里的等值查询</h1>
<p>有同学对“等值查询”提出了疑问：等值查询和“遍历”有什么区别？为什么我们文章的例子里面，where 条件是不等号，这个过程里也有等值查询？</p>
<p>我们一起来看下这个例子，分析一下这条查询语句的加锁范围：</p>
<pre><code>begin;
select * from t where id&gt;9 and id&lt;12 order by id desc for update;
</code></pre>
<p>利用上面的加锁规则，我们知道这个语句的加锁范围是主键索引上的 (0,5]、(5,10] 和 (10, 15)。也就是说，id=15 这一行，并没有被加上行锁。为什么呢？</p>
<p>我们说加锁单位是 next-key lock，都是前开后闭区间，但是这里用到了优化 2，即索引上的等值查询，向右遍历的时候 id=15 不满足条件，所以 next-key lock 退化为了间隙锁 (10, 15)。</p>
<p>但是，我们的查询语句中 where 条件是大于号和小于号，这里的“等值查询”又是从哪里来的呢？</p>
<p>要知道，加锁动作是发生在语句执行过程中的，所以你在分析加锁行为的时候，要从索引上的数据结构开始。这里，我再把这个过程拆解一下。</p>
<p>如图 1 所示，是这个表的索引 id 的示意图。</p>
<p><img src="assets/ac1aa07860c565b907b32c5f75c4f2bb.png" alt="img" /></p>
<p>图 1 索引 id 示意图</p>
<ol>
<li>首先这个查询语句的语义是 order by id desc，要拿到满足条件的所有行，优化器必须先找到“第一个 id&lt;12 的值”。</li>
<li>这个过程是通过索引树的搜索过程得到的，在引擎内部，其实是要找到 id=12 的这个值，只是最终没找到，但找到了 (10,15) 这个间隙。</li>
<li>然后向左遍历，在遍历过程中，就不是等值查询了，会扫描到 id=5 这一行，所以会加一个 next-key lock (0,5]。</li>
</ol>
<p>也就是说，在执行过程中，通过树搜索的方式定位记录的时候，用的是“等值查询”的方法。</p>
<h1>等值查询的过程</h1>
<p>与上面这个例子对应的，是 @发条橙子同学提出的问题：下面这个语句的加锁范围是什么？</p>
<pre><code>begin;
select id from t where c in(5,20,10) lock in share mode;
</code></pre>
<p>这条查询语句里用的是 in，我们先来看这条语句的 explain 结果。
<img src="assets/8a089159c82c1458b26e2756583347b3.png" alt="img" /></p>
<p>图 2 in 语句的 explain 结果</p>
<p>可以看到，这条 in 语句使用了索引 c 并且 rows=3，说明这三个值都是通过 B+ 树搜索定位的。</p>
<p>在查找 c=5 的时候，先锁住了 (0,5]。但是因为 c 不是唯一索引，为了确认还有没有别的记录 c=5，就要向右遍历，找到 c=10 才确认没有了，这个过程满足优化 2，所以加了间隙锁 (5,10)。</p>
<p>同样的，执行 c=10 这个逻辑的时候，加锁的范围是 (5,10] 和 (10,15)；执行 c=20 这个逻辑的时候，加锁的范围是 (15,20] 和 (20,25)。</p>
<p>通过这个分析，我们可以知道，这条语句在索引 c 上加的三个记录锁的顺序是：先加 c=5 的记录锁，再加 c=10 的记录锁，最后加 c=20 的记录锁。</p>
<p>你可能会说，这个加锁范围，不就是从 (5,25) 中去掉 c=15 的行锁吗？为什么这么麻烦地分段说呢？</p>
<p>因为我要跟你强调这个过程：这些锁是“在执行过程中一个一个加的”，而不是一次性加上去的。</p>
<p>理解了这个加锁过程之后，我们就可以来分析下面例子中的死锁问题了。</p>
<p>如果同时有另外一个语句，是这么写的：</p>
<pre><code>select id from t where c in(5,20,10) order by c desc for update;
</code></pre>
<p>此时的加锁范围，又是什么呢？</p>
<p>我们现在都知道间隙锁是不互锁的，但是这两条语句都会在索引 c 上的 c=5、10、20 这三行记录上加记录锁。</p>
<p>这里你需要注意一下，由于语句里面是 order by c desc， 这三个记录锁的加锁顺序，是先锁 c=20，然后 c=10，最后是 c=5。</p>
<p>也就是说，这两条语句要加锁相同的资源，但是加锁顺序相反。当这两条语句并发执行的时候，就可能出现死锁。</p>
<p>关于死锁的信息，MySQL 只保留了最后一个死锁的现场，但这个现场还是不完备的。</p>
<p>有同学在评论区留言到，希望我能展开一下怎么看死锁。现在，我就来简单分析一下上面这个例子的死锁现场。</p>
<h1>怎么看死锁？</h1>
<p>图 3 是在出现死锁后，执行 show engine innodb status 命令得到的部分输出。这个命令会输出很多信息，有一节 LATESTDETECTED DEADLOCK，就是记录的最后一次死锁信息。
<img src="assets/a7dccb91bc17d12746703eb194775cf6.png" alt="img" /></p>
<p>图 3 死锁现场</p>
<p>我们来看看这图中的几个关键信息。</p>
<ol>
<li>这个结果分成三部分：
<ul>
<li>(1) TRANSACTION，是第一个事务的信息；</li>
<li>(2) TRANSACTION，是第二个事务的信息；</li>
<li>WE ROLL BACK TRANSACTION (1)，是最终的处理结果，表示回滚了第一个事务。</li>
</ul>
</li>
<li>第一个事务的信息中：
<ul>
<li>WAITING FOR THIS LOCK TO BE GRANTED，表示的是这个事务在等待的锁信息；</li>
<li>index c of table <code>test</code>.<code>t</code>，说明在等的是表 t 的索引 c 上面的锁；</li>
<li>lock mode S waiting 表示这个语句要自己加一个读锁，当前的状态是等待中；</li>
<li>Record lock 说明这是一个记录锁；</li>
<li>n_fields 2 表示这个记录是两列，也就是字段 c 和主键字段 id；</li>
<li>0: len 4; hex 0000000a; asc ;; 是第一个字段，也就是 c。值是十六进制 a，也就是 10；</li>
<li>1: len 4; hex 0000000a; asc ;; 是第二个字段，也就是主键 id，值也是 10；</li>
<li>这两行里面的 asc 表示的是，接下来要打印出值里面的“可打印字符”，但 10 不是可打印字符，因此就显示空格。</li>
<li>第一个事务信息就只显示出了等锁的状态，在等待 (c=10,id=10) 这一行的锁。</li>
<li>当然你是知道的，既然出现死锁了，就表示这个事务也占有别的锁，但是没有显示出来。别着急，我们从第二个事务的信息中推导出来。</li>
</ul>
</li>
<li>第二个事务显示的信息要多一些：
<ul>
<li>“ HOLDS THE LOCK(S)”用来显示这个事务持有哪些锁；</li>
<li>index c of table <code>test</code>.<code>t</code> 表示锁是在表 t 的索引 c 上；</li>
<li>hex 0000000a 和 hex 00000014 表示这个事务持有 c=10 和 c=20 这两个记录锁；</li>
<li>WAITING FOR THIS LOCK TO BE GRANTED，表示在等 (c=5,id=5) 这个记录锁。</li>
</ul>
</li>
</ol>
<p>从上面这些信息中，我们就知道：</p>
<ol>
<li>“lock in share mode”的这条语句，持有 c=5 的记录锁，在等 c=10 的锁；</li>
<li>“for update”这个语句，持有 c=20 和 c=10 的记录锁，在等 c=5 的记录锁。</li>
</ol>
<p>因此导致了死锁。这里，我们可以得到两个结论：</p>
<ol>
<li>由于锁是一个个加的，要避免死锁，对同一组资源，要按照尽量相同的顺序访问；</li>
<li>在发生死锁的时刻，for update 这条语句占有的资源更多，回滚成本更大，所以 InnoDB 选择了回滚成本更小的 lock in share mode 语句，来回滚。</li>
</ol>
<h1>怎么看锁等待？</h1>
<p>看完死锁，我们再来看一个锁等待的例子。</p>
<p>在第 21 篇文章的评论区，@Geek_9ca34e 同学做了一个有趣验证，我把复现步骤列出来：</p>
<p><img src="assets/af3602b81aeb49e33577ba372d220a75.png" alt="img" /></p>
<p>图 4 delete 导致间隙变化</p>
<p>可以看到，由于 session A 并没有锁住 c=10 这个记录，所以 session B 删除 id=10 这一行是可以的。但是之后，session B 再想 insert id=10 这一行回去就不行了。</p>
<p>现在我们一起看一下此时 show engine innodb status 的结果，看看能不能给我们一些提示。锁信息是在这个命令输出结果的 TRANSACTIONS 这一节。你可以在文稿中看到这张图片
<img src="assets/c3744fb7b61df2a5b45b8eb1f2a853a6.png" alt="img" /></p>
<p>图 5 锁等待信息</p>
<p>我们来看几个关键信息。</p>
<ol>
<li>index PRIMARY of table <code>test</code>.<code>t</code> ，表示这个语句被锁住是因为表 t 主键上的某个锁。</li>
<li>lock_mode X locks gap before rec insert intention waiting 这里有几个信息：
<ul>
<li>insert intention 表示当前线程准备插入一个记录，这是一个插入意向锁。为了便于理解，你可以认为它就是这个插入动作本身。</li>
<li>gap before rec 表示这是一个间隙锁，而不是记录锁。</li>
</ul>
</li>
<li>那么这个 gap 是在哪个记录之前的呢？接下来的 0~4 这 5 行的内容就是这个记录的信息。</li>
<li>n_fields 5 也表示了，这一个记录有 5 列：
<ul>
<li>0: len 4; hex 0000000f; asc ;; 第一列是主键 id 字段，十六进制 f 就是 id=15。所以，这时我们就知道了，这个间隙就是 id=15 之前的，因为 id=10 已经不存在了，它表示的就是 (5,15)。</li>
<li>1: len 6; hex 000000000513; asc ;; 第二列是长度为 6 字节的事务 id，表示最后修改这一行的是 trx id 为 1299 的事务。</li>
<li>2: len 7; hex b0000001250134; asc % 4;; 第三列长度为 7 字节的回滚段信息。可以看到，这里的 acs 后面有显示内容 (% 和 4)，这是因为刚好这个字节是可打印字符。</li>
<li>后面两列是 c 和 d 的值，都是 15。</li>
</ul>
</li>
</ol>
<p>因此，我们就知道了，由于 delete 操作把 id=10 这一行删掉了，原来的两个间隙 (5,10)、(10,15）变成了一个 (5,15)。</p>
<p>说到这里，你可以联合起来再思考一下这两个现象之间的关联：</p>
<ol>
<li>session A 执行完 select 语句后，什么都没做，但它加锁的范围突然“变大”了；</li>
<li>第 21 篇文章的课后思考题，当我们执行 select * from t where c&gt;=15 and c&lt;=20 order by c desc lock in share mode; 向左扫描到 c=10 的时候，要把 (5, 10] 锁起来。</li>
</ol>
<p>也就是说，所谓“间隙”，其实根本就是由“这个间隙右边的那个记录”定义的。</p>
<h1>update 的例子</h1>
<p>看过了 insert 和 delete 的加锁例子，我们再来看一个 update 语句的案例。在留言区中 @信信 同学做了这个试验：</p>
<p><img src="assets/61c1ceea7b59201649c2514c9db864a7.png" alt="img" /></p>
<p>图 6 update 的例子</p>
<p>你可以自己分析一下，session A 的加锁范围是索引 c 上的 (5,10]、(10,15]、(15,20]、(20,25] 和 (25,supremum]。</p>
<blockquote>
<p>注意：根据 c&gt;5 查到的第一个记录是 c=10，因此不会加 (0,5] 这个 next-key lock。</p>
</blockquote>
<p>之后 session B 的第一个 update 语句，要把 c=5 改成 c=1，你可以理解为两步：</p>
<ol>
<li>插入 (c=1, id=5) 这个记录；</li>
<li>删除 (c=5, id=5) 这个记录。</li>
</ol>
<p>按照我们上一节说的，索引 c 上 (5,10) 间隙是由这个间隙右边的记录，也就是 c=10 定义的。所以通过这个操作，session A 的加锁范围变成了图 7 所示的样子：
<img src="assets/d2f6a0c46dd8d12f6a90dacc466d53e9.png" alt="img" /></p>
<p>图 7 session B 修改后， session A 的加锁范围</p>
<p>好，接下来 session B 要执行 update t set c = 5 where c = 1 这个语句了，一样地可以拆成两步：</p>
<ol>
<li>插入 (c=5, id=5) 这个记录；</li>
<li>删除 (c=1, id=5) 这个记录。</li>
</ol>
<p>第一步试图在已经加了间隙锁的 (1,10) 中插入数据，所以就被堵住了。</p>
<h1>小结</h1>
<p>今天这篇文章，我用前面[第 20]和[第 21 篇]文章评论区的几个问题，再次跟你复习了加锁规则。并且，我和你重点说明了，分析加锁范围时，一定要配合语句执行逻辑来进行。</p>
<p>在我看来，每个想认真了解 MySQL 原理的同学，应该都要能够做到：通过 explain 的结果，就能够脑补出一个 SQL 语句的执行流程。达到这样的程度，才算是对索引组织表、索引、锁的概念有了比较清晰的认识。你同样也可以用这个方法，来验证自己对这些知识点的掌握程度。</p>
<p>在分析这些加锁规则的过程中，我也顺便跟你介绍了怎么看 show engine innodb status 输出结果中的事务信息和死锁信息，希望这些内容对你以后分析现场能有所帮助。</p>
<p>老规矩，即便是答疑文章，我也还是要留一个课后问题给你的。</p>
<p>上面我们提到一个很重要的点：所谓“间隙”，其实根本就是由“这个间隙右边的那个记录”定义的。</p>
<p>那么，一个空表有间隙吗？这个间隙是由谁定义的？你怎么验证这个结论呢？</p>
<p>你可以把你关于分析和验证方法写在留言区，我会在下一篇文章的末尾和你讨论这个问题。感谢你的收听，也欢迎你把这篇文章分享给更多的朋友一起阅读。</p>
<h1>上期问题时间</h1>
<p>我在上一篇文章最后留给的问题，是分享一下你关于业务监控的处理经验。</p>
<p>在这篇文章的评论区，很多同学都分享了不错的经验。这里，我就选择几个比较典型的留言，和你分享吧：</p>
<ul>
<li>@老杨同志 回答得很详细。他的主要思路就是关于服务状态和服务质量的监控。其中，服务状态的监控，一般都可以用外部系统来实现；而服务的质量的监控，就要通过接口的响应时间来统计。</li>
<li>@Ryoma 同学，提到服务中使用了 healthCheck 来检测，其实跟我们文中提到的 select 1 的模式类似。</li>
<li>@强哥 同学，按照监控的对象，将监控分成了基础监控、服务监控和业务监控，并分享了每种监控需要关注的对象。</li>
</ul>
</div>
</div>
<div>
<div style="float: left">
<a href="/专栏/MySQL实战45讲/29 如何判断一个数据库是不是出问题了？.md">上一页</a>
</div>
<div style="float: right">
<a href="/专栏/MySQL实战45讲/31 误删数据后除了跑路，还能怎么办？.md">下一页</a>
</div>
</div>
</div>
</div>
</div>
</div>
<a class="off-canvas-overlay" onclick="hide_canvas()"></a>
</div>
<script defer src="https://static.cloudflareinsights.com/beacon.min.js/v652eace1692a40cfa3763df669d7439c1639079717194" integrity="sha512-Gi7xpJR8tSkrpF7aordPZQlW2DLtzUlZcumS8dMQjwDHEnw9I7ZLyiOj/6tZStRBGtGgN6ceN6cMH8z7etPGlw==" data-cf-beacon='{"rayId":"709972cbddd83d60","version":"2021.12.0","r":1,"token":"1f5d475227ce4f0089a7cff1ab17c0f5","si":100}' crossorigin="anonymous"></script>
</body>
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-NPSEEVD756"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag() {
dataLayer.push(arguments);
}
gtag('js', new Date());
gtag('config', 'G-NPSEEVD756');
var path = window.location.pathname
var cookie = getCookie("lastPath");
console.log(path)
if (path.replace("/", "") === "") {
if (cookie.replace("/", "") !== "") {
console.log(cookie)
document.getElementById("tip").innerHTML = "<a href='" + cookie + "'>跳转到上次进度</a>"
}
} else {
setCookie("lastPath", path)
}
function setCookie(cname, cvalue) {
var d = new Date();
d.setTime(d.getTime() + (180 * 24 * 60 * 60 * 1000));
var expires = "expires=" + d.toGMTString();
document.cookie = cname + "=" + cvalue + "; " + expires + ";path = /";
}
function getCookie(cname) {
var name = cname + "=";
var ca = document.cookie.split(';');
for (var i = 0; i < ca.length; i++) {
var c = ca[i].trim();
if (c.indexOf(name) === 0) return c.substring(name.length, c.length);
}
return "";
}
</script>
</html>
Reference in New Issue View Git Blame Copy Permalink