mysql锁SELECT FOR UPDATE【转】

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,高可用系列 2核4GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介: MySQL 使用SELECT ... FOR UPDATE 做事务写入前的确认以MySQL 的InnoDB 为例,预设的Tansaction isolation level 为REPEATABLE READ,在SELECT 的读取锁定主要分为两种方式:SELECT ... LOCK IN SHAREMODE SELECT ... FOR UPDATE这两种方式在事务(Transaction) 进行当中SELECT 到同一个数据表时,都必须等待其它事务数据被提交(Commit)后才会执行。

MySQL 使用SELECT ... FOR UPDATE 做事务写入前的确认

以MySQL 的InnoDB 为例,预设的Tansaction isolation level 为REPEATABLE READ,在SELECT 的读取锁定主要分为两种方式:

SELECT ... LOCK IN SHARE

MODE SELECT ... FOR UPDATE

这两种方式在事务(Transaction) 进行当中SELECT 到同一个数据表时,都必须等待其它事务数据被提交(Commit)后才会执行。而主要的不同在于LOCK IN SHARE MODE 在有一方事务要Update 同一个表单时很容易造成死锁 。

简单的说,如果SELECT 后面若要UPDATE 同一个表单,最好使用SELECT ... UPDATE。

举个例子: 假设商品表单products 内有一个存放商品数量的quantity ,在订单成立之前必须先确定quantity 商品数量是否足够(quantity>0) ,然后才把数量更新为1。

不安全的做法:

SELECT quantity FROM products WHERE id=3; UPDATE products SET quantity = 1 WHERE id=3;

为什么不安全呢?

少量的状况下或许不会有问题,但是大量的数据存取「铁定」会出问题。

如果我们需要在quantity>0 的情况下才能扣库存,假设程序在第一行SELECT 读到的quantity 是2 ,看起来数字没有错,但是当MySQL 正准备要UPDATE 的时候,可能已经有人把库存扣成0 了,但是程序却浑然不知,将错就错的UPDATE 下去了。

因此必须透过的事务机制来确保读取及提交的数据都是正确的。

于是我们在MySQL 就可以这样测试: (注1)

SET AUTOCOMMIT=0; BEGIN WORK; SELECT quantity FROM products WHERE id=3 FOR UPDATE;


此时products 数据中id=3 的数据被锁住(注3),其它事务必须等待此次事务 提交后才能执行

SELECT * FROM products WHERE id=3 FOR UPDATE (注2)

如此可以确保quantity 在别的事务读到的数字是正确的。


UPDATE products SET quantity = '1' WHERE id=3 ; COMMIT WORK;


提交(Commit)写入数据库,products 解锁。

  • 注1: BEGIN/COMMIT 为事务的起始及结束点,可使用二个以上的MySQL Command 视窗来交互观察锁定的状况。
  • 注2: 在事务进行当中,只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一笔数据时会等待其它事务结束后才执行,一般SELECT ... 则不受此影响。
  • 注3: 由于InnoDB 预设为Row-level Lock,数据列的锁定可参考这篇。
  • 注4: InnoDB 表单尽量不要使用LOCK TABLES 指令,若情非得已要使用,请先看官方对于InnoDB 使用LOCK TABLES 的说明,以免造成系统经常发生死锁。

MySQL SELECT ... FOR UPDATE 的Row Lock 与Table Lock

上面介绍过SELECT ... FOR UPDATE 的用法,不过锁定(Lock)的数据是判别就得要注意一下了。由于InnoDB 预设是Row-Level Lock,所以只有「明确」的指定主键,MySQL 才会执行Row lock (只锁住被选取的数据) ,否则MySQL 将会执行Table Lock (将整个数据表单给锁住)。

举个例子:

假设有个表单products ,里面有id 跟name 二个栏位,id 是主键。

例1: (明确指定主键,并且有此数据,row lock)

SELECT * FROM products WHERE id='3' FOR UPDATE;

例2: (明确指定主键,若查无此数据,无lock)

SELECT * FROM products WHERE id='-1' FOR UPDATE;

例2: (无主键,table lock)

SELECT * FROM products WHERE name='Mouse' FOR UPDATE;

例3: (主键不明确,table lock)

SELECT * FROM products WHERE id<>'3' FOR UPDATE;

例4: (主键不明确,table lock)

SELECT * FROM products WHERE id LIKE '3' FOR UPDATE;

  • 注1: FOR UPDATE 仅适用于InnoDB,且必须在事务区块(BEGIN/COMMIT)中才能生效。
  • 注2: 要测试锁定的状况,可以利用MySQL 的Command Mode ,开二个视窗来做测试。
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
相关文章
Cron表达式每隔两小时执行一次
Cron表达式每隔两小时执行一次
505 1
|
人工智能 自然语言处理 搜索推荐
如何让智能客服像真人一样对话?容联七陌揭秘:多Agent大模型
科技云报到原创。 经历了多年的“答非所问”、“一问三不知”,很多人已经厌倦了所谓的“智能客服”。哪怕是技术已经非常成熟、可以模拟真人发音的外呼机器人,也会因为“机感”重而被用户迅速挂机或转向人工客服。 智能客服似乎遇到了一道坎,在理解用户、和用户对话方面,始终无法实现真正的“智能”。然而大模型技术的出现,让智能客服看到了前所未有的曙光——基于大模型特有的生成式技术和智能的涌现,让智能客服越来越逼近人们想象中的样子。 但问题是,仅有大模型就够了吗?大模型技术要如何引入智能客服才能落地?落地后的大模型究竟如何在智能客服具体场景中发挥作用?又能为客服行业带来了哪些改变?更进一步,对于企业和
785 1
如何让智能客服像真人一样对话?容联七陌揭秘:多Agent大模型
|
开发者
如何画好一张架构图/业务图/流程图,掌握4个关键点
本文分享了如何制作出有帮助的图表,强调了即使是开发者也需要良好的绘图技巧。文章列举了常见的图表类型,如代码实现图、技术架构图、业务流程图、技术链路图、交互时序图和业务架构图,并指出好的图表应具备结构清晰、外表美观和内容完整的特点。为了达到这些标准,作者推荐了设计的四大原则:亲密性、对齐、对比和重复,以及色轮的运用来提升美感。此外,还介绍了黄金分割构图法以增加视觉吸引力。最后,强调了以终为始的设计思路,确保图表能独立传达完整的信息,并鼓励读者实践这些技巧,提升工作和生活中的沟通效率。
1086 1
如何画好一张架构图/业务图/流程图,掌握4个关键点
|
存储 前端开发 搜索推荐
13:Session机制实现用户登录与注销功能-Java Web
13:Session机制实现用户登录与注销功能-Java Web
959 3
|
消息中间件 存储 Go
Golang微服务框架Kratos应用NSQ消息队列
NSQ是一个基于Go语言的分布式实时消息平台,它基于MIT开源协议发布,由bitly公司开源出来的一款简单易用的消息中间件。 NSQ可用于大规模系统中的实时消息服务,并且每天能够处理数亿级别的消息,其设计目标是为在分布式环境下运行的去中心化服务提供一个强大的基础架构。 NSQ具有分布式、去中心化的拓扑结构,该结构具有无单点故障、故障容错、高可用性以及能够保证消息的可靠传递的特征。NSQ非常容易配置和部署,且具有最大的灵活性,支持众多消息协议。
246 1
|
消息中间件 缓存 NoSQL
高并发缓存队列防止溢出解决方案
高并发缓存队列防止溢出解决方案
416 0
|
缓存 算法
总结两种常见的长列表分页缓存策略
通常,对于长列表加载的场景,都需要进行分页, 如最近的世界杯体育垂站项目中的赛程页,评论流,直播流。而为了提高分页加载的性能,往往需要对分页进行缓存。 下面总结对两种常见的分页缓存的策略, 适用场景以及各自的优缺点。     策略一: 直接对分页结果缓存 顾名思义,就是直接缓存每次分页查询的结果。  
8377 0
|
前端开发 Java 数据库连接
超详细讲解SpringMVC三层架构
超详细讲解SpringMVC三层架构
869 0
|
网络架构
web统计:UV、IP、PV、VV
web统计:UV、IP、PV、VV
690 0
|
SQL Java 关系型数据库