MySQL 实战 45 讲
林晓斌
网名丁奇,前腾讯云数据库负责人
224872 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
实践篇 (37讲)
特别放送 (1讲)
结课测试 (1讲)
MySQL 实战 45 讲
15
15
1.0x
00:00/00:00
登录|注册

07 | 行锁功过:怎么减少行锁对性能的影响?

逻辑上的多行
控制并发度
死锁检测策略
死锁概念
安排事务语句顺序
优化锁冲突
死锁和死锁检测
两阶段锁协议
删除表数据的方法
行锁
性能优化

该思维导图由 AI 生成,仅供参考

在上一篇文章中,我跟你介绍了 MySQL 的全局锁和表级锁,今天我们就来讲讲 MySQL 的行锁。
MySQL 的行锁是在引擎层由各个引擎自己实现的。但并不是所有的引擎都支持行锁,比如 MyISAM 引擎就不支持行锁。不支持行锁意味着并发控制只能使用表锁,对于这种引擎的表,同一张表上任何时刻只能有一个更新在执行,这就会影响到业务并发度。InnoDB 是支持行锁的,这也是 MyISAM 被 InnoDB 替代的重要原因之一。
我们今天就主要来聊聊 InnoDB 的行锁,以及如何通过减少锁冲突来提升业务并发度。
顾名思义,行锁就是针对数据表中行记录的锁。这很好理解,比如事务 A 更新了一行,而这时候事务 B 也要更新同一行,则必须等事务 A 的操作完成后才能进行更新。
当然,数据库中还有一些没那么一目了然的概念和设计,这些概念如果理解和使用不当,容易导致程序出现非预期行为,比如两阶段锁。

从两阶段锁说起

我先给你举个例子。在下面的操作序列中,事务 B 的 update 语句执行时会是什么现象呢?假设字段 id 是表 t 的主键。
这个问题的结论取决于事务 A 在执行完两条 update 语句后,持有哪些锁,以及在什么时候释放。你可以验证一下:实际上事务 B 的 update 语句会被阻塞,直到事务 A 执行 commit 之后,事务 B 才能继续执行。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文主要讨论了MySQL的行锁对数据库性能的影响以及如何通过合理的事务设计来减少锁冲突,提升并发度。文章首先介绍了行锁的概念和两阶段锁协议,强调了行锁在事务结束时才会释放的特点。通过一个电影票在线交易业务的例子,说明了如何合理安排事务中的操作顺序以减少锁等待,提升并发度。此外,文章还提到了死锁和死锁检测对数据库性能的影响。作者提出了三种方案来减少死锁对数据库的影响,主要是控制访问相同资源的并发事务量。最后,作者留下了一个问题,讨论了三种不同的删除表数据的方法及其影响。整体而言,本文通过深入讨论MySQL的行锁特性和死锁问题,为读者提供了对数据库性能优化的重要思路和方法。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《MySQL 实战 45 讲》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(378)

  • 最新
  • 精选
  • 蓝天
    置顶
    老师:上一节讲的dml时会产生读MDL锁(表锁),也就是update会持有读MDL。读和读不互斥。但是对于行锁来说。两个update同时更新一条数据是互斥的。这个是因为多种锁同时存在时,以粒度最小的锁为准的原因么?

    作者回复: 不是“以粒度最小为准” 而是如果有多种锁,必须得“全部不互斥”才能并行,只要有一个互斥,就得等。 好问题

    2019-01-09
    9
    131
  • 三木禾
    置顶
    老师,如果开启事务,然后进行死锁检测,如果发现有其它线程因为这个线程的加入,导致其它线程的死锁,这个流程能帮着分析一下么

    作者回复: 好问题 理论上说,之前没死锁,现在A加进来,出现了死锁,那么死锁的环里面肯定包含A, 因此只要从A出发去扫就好了

    2018-12-14
    5
    73
  • 会玩code
    置顶
    老师,关于死锁检测innodb_deadlock_detect我想请教一下,是每条事务执行前都会进行检测吗?如果是这样,即使简单的更新单个表的语句,当每秒的并发量达到上千的话,岂不是也会消耗大量资源用于死锁检测吗?

    作者回复: 是个好问题 如果他要加锁访问的行上有锁,他才要检测。 这里面我担心你有两个误解,说明下: 1. 一致性读不会加锁,就不需要做死锁检测; 2. 并不是每次死锁检测都都要扫所有事务。比如某个时刻,事务等待状态是这样的: B在等A, D在等C, 现在来了一个E,发现E需要等D,那么E就判断跟D、C是否会形成死锁,这个检测不用管B和A

    2018-12-03
    27
    529
  • 武者
    置顶
    老师 你好 有以下情况 帮忙分析下会锁表不 update a,b set a.name = b.name where a.uid=b.uid and b.group=1; update c,b set c.age=b.age where c.uid=b.uid and b.group = 1; 如果两个语句同时执行期间 是不是有个执行不了 要等b解锁。还是说没有更新b的字段b不会锁,两个可并行执行 请老师指导下

    作者回复: 这个你得同时贴表结构。 还有,会不会锁,不是验证一下就可以吗,两个都用begin + 语句, 两阶段锁协议会帮助你😄

    2018-11-29
    9
    18
  • 某、人
    置顶
    老师,针对我的第一个问题。我就是想问怎么能拿到比较全得死锁信息以及把这些信息保存到文件里。 第二个问题,如果reset以后,是不是就失去了长连接的意义了呢?相当于再次进行连接。

    作者回复: 1. 就是持续监控,发现新的就存起来 2. 不会,reset_connection只是复位状态,恢复到连接和权限验证之后的状态,没有重连

    2018-11-28
    3
    43
  • 荒漠甘泉
    置顶
    老师,本节课讲的不支持行锁的引擎,只能使用表锁,而表锁同一张表在同一时刻只能有一个更新。但是上节课讲的表级锁中的MDL锁,dml语句会产生MDL读锁,而MDL读锁不是互斥的,也就是说一张表可以同时有多个dml语句操作。感觉这两种说法有点矛盾,请老师解惑!

    作者回复: 不矛盾,MDL锁和表锁是两个不同的结构。 比如: 你要在myisam 表上更新一行,那么会加MDL读锁和表的写锁; 然后同时另外一个线程要更新这个表上另外一行,也要加MDL读锁和表写锁。 第二个线程的*MDL读锁是能成功加上*的,但是被表写锁堵住了。从语句现象上看,就是第二个线程要等第一个线程执行完成。

    2018-11-28
    33
    190
  • bluefantasy3
    置顶
    请教老师一个问题: innodb行级锁是通过锁索引记录实现的。如果update的列没建索引,即使只update一条记录也会锁定整张表吗?比如update t set t.name='abc' where t.name='cde'; name字段无索引。为何innodb不优化一下,只锁定name='cde'的列?

    作者回复: 第一个问题是好问题,我加到答疑文章中。简单的回答:是的。但是你可以再往前考虑一下,如果是 你的update 语句后面加个limit 1, 会怎么锁? Innodb支持行锁,没有支持“列锁” 哈😄

    2018-11-28
    75
    253
  • Tony Du
    方案一,事务相对较长,则占用锁的时间较长,会导致其他客户端等待资源时间较长。 方案二,串行化执行,将相对长的事务分成多次相对短的事务,则每次事务占用锁的时间相对较短,其他客户端在等待相应资源的时间也较短。这样的操作,同时也意味着将资源分片使用(每次执行使用不同片段的资源),可以提高并发性。 方案三,人为自己制造锁竞争,加剧并发量。 方案二相对比较好,具体还要结合实际业务场景。 另,对于innodb的行锁,我觉得可以增加一讲,如何加锁(依赖于具体的隔离级别,是否有索引,是否是唯一索引,SQL的执行计划),特别是在RR隔离级别下的GAP锁,对于innodb,RR级别是可以防止幻读的。

    作者回复: 分析得很好。 嗯嗯索引和锁的内容很多,也是需要慢慢安排😄 突然上概念怕大家看得不开心😓

    2018-11-28
    6
    182
  • WL
    继续把该讲内容总结为几个问题, 大家复习的时候可以先尝试回答这些问题检查自己的掌握程度: 1. 两阶段锁的概念是什么? 对事务使用有什么帮助? 2. 死锁的概念是什么? 举例说明出现死锁的情况. 3. 死锁的处理策略有哪两种? 4. 等待超时处理死锁的机制什么?有什么局限? 5. 死锁检测处理死锁的机制是什么? 有什么局限? 6. 有哪些思路可以解决热点更新导致的并发问题?

    作者回复: 继续手动👍🏿

    2018-12-01
    6
    164
  • 大白给小白讲故事
    总结: 两阶段锁:在 InnoDB 事务中,行锁是在需要的时候才加上的,但并不是不需要了就立刻释放, 而是要等到事务结束时才释放。 建议:如果你的事务中需要锁多个行,要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。 死锁:当并发系统中不同线程出现循环资源依赖,涉及的线程都在等待别的线程释放资源时,就会导致这几个线程都进入无限等待的状态。 解决方案: 1、通过参数 innodb_lock_wait_timeout 根据实际业务场景来设置超时时间,InnoDB引擎默认值是50s。 2、发起死锁检测,发现死锁后,主动回滚死锁链条中的某一个事务,让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on,表示开启这个逻辑(默认是开启状态)。 如何解决热点行更新导致的性能问题? 1、如果你能确保这个业务一定不会出现死锁,可以临时把死锁检测关闭掉。一般不建议采用 2、控制并发度,对应相同行的更新,在进入引擎之前排队。这样在InnoDB内部就不会有大量的死锁检测工作了。 3、将热更新的行数据拆分成逻辑上的多行来减少锁冲突,但是业务复杂度可能会大大提高。 innodb行级锁是通过锁索引记录实现的,如果更新的列没建索引是会锁住整个表的。

    作者回复: 👍🏿这个总结

    2018-11-29
    9
    138
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部