MySQL Innodb 中的锁

MySQL Innodb 中的锁

锁是用来解决并发冲突的必要手段,MySQL 中的并发主要是指多个线程同时对同一个数据库进行操作,其中不同线程可能代表不同的事务,本质上也就是对共享资源的不同事务的同时访问。

Innodb 支持行级锁和意向锁。行级锁就是对行记录进行加锁,行级锁也分为两种类型,一种是共享锁( S 锁),一种是排他锁( X 锁)。意向锁为表级别的锁,也就是将锁定的对象分为多个层次,意向锁意味着事务希望在更细粒度上进行加锁,一般来说,意向锁是从上往下(数据库->表->页->记录)进行加锁,其中任何一个部分导致等待,那么该操作都会需要等待粗粒度的锁的完成。

读的锁定操作

一致性非锁定读

MySQL 的默认事务隔离级别是 Repeatable Read,在事务隔离为 Repeatable Read 和 Read Committed 级别下,默认的读取方式即为一致性非锁定读。一致性非锁定读即为在访问行记录时,不需要等待该行上的 X 锁释放。Innodb 的一致性非锁定读是以多版本控制实现的,在多版本控制中,会保存修改之前数据的快照,作为恢复使用。

需要注意的是:在 Repeatable Read 和 Read Committed 的两种级别下的一致性非锁定读也是不同的,Repeatable Read 隔离级别下,总是读取事务开始时的行数据,而 Read Committed 模式下总是读取该行版本上的最新快照。

一致性锁定读

默认情况下,在 Repeatable Read 和 Read Committed 隔离界别下,SELECT 语句对一行的读取是使用一致性非锁定读的,用户可以通过指定 SELECT 语句使用一致性锁定读,例如:

  1. SELECT ... FOR UPDATE
  2. SELECT ... LOCK IN SHARE MODE

这两种方法可以分别给行记录加上一个 X 锁和 S 锁。

外键和锁

对于一个外键的更新和插入,首先需要查询父表中的记录,即主动对父表加一个 S 锁,这里必须使用一致性锁定读。如果不这么做,当另外事务 A 对父表的行记录进行了删除操作,而事务 B 打算在子表中添加一行与父表具有外键关系的行,事务 B 会读到存在该外键,从而添加(从快照中读取),但是实际上当事务 A 提交后,父表中将不存在该主键,从而导致父子表中完整性被破坏。

行锁的三种方法

Record Lock:单个行记录上的锁。

Gap Lock:间隙锁,不包含记录本身。

Next-Key Lock:锁定一个范围同时也锁定记录本身。

在查询的列是唯一索引时,Next-Key Lock 会降级为 Record Lock,以提高并发效率。

在 Repeatable Read 和 Read Committed 情况下使用行锁的方法不同,在 Repeatable Read 下,使用 Next-Key Lock,而在 Read Committed 情况下,使用 Record Lock。

原文地址:https://www.cnblogs.com/bdsir/p/8868510.html

时间: 2024-11-04 00:45:49

MySQL Innodb 中的锁的相关文章

详解 MySql InnoDB 中的三种行锁(记录锁、间隙锁与临键锁)

详解 MySql InnoDB 中的三种行锁(记录锁.间隙锁与临键锁) 前言 InnoDB 通过 MVCC 和 NEXT-KEY Locks,解决了在可重复读的事务隔离级别下出现幻读的问题.MVCC 我先挖个坑,日后再细讲,这篇文章我们主要来谈谈那些可爱的锁. 什么是幻读? 幻读是在可重复读的事务隔离级别下会出现的一种问题,简单来说,可重复读保证了当前事务不会读取到其他事务已提交的 UPDATE 操作.但同时,也会导致当前事务无法感知到来自其他事务中的 INSERT 或 DELETE 操作,这就

MySQL InnoDB中的事务隔离级别和锁的关系

前言: 我们都知道事务的几种性质,数据库为了维护这些性质,尤其是一致性和隔离性,一般使用加锁这种方式.同时数据库又是个高并发的应用,同一时间会有大量的并发访问,如果加锁过度,会极大的降低并发处理能力.所以对于加锁的处理,可以说就是数据库对于事务处理的精髓所在.这里通过分析MySQL中InnoDB引擎的加锁机制,来抛砖引玉,让读者更好的理解,在事务处理中数据库到底做了什么. 一.一次封锁or两段锁因为有大量的并发访问,为了预防死锁,一般应用中推荐使用一次封锁法,就是在方法的开始阶段,已经预先知道会

Innodb中的锁

虽然比较擅长的是Oracle,但是公司使用的是MySQL数据库,所以不得不对MySQL数据库多研究一下.今天就谈一下MySQL中的锁. 谈锁之前,要明白为什么会有锁这种东西.之所以有锁,大部分情况下是为了实现事务(transaction)之间的隔离,那么事务之间有几种隔离方式,各种隔离方式又是为了达到什么效果呢?先来说一下各种读现象. 脏读:即一个事务A读取了事务B还没有提交过的数据: 不可重复读:即事务A在第一次按照某条SQL语句读取后跟第二次按照相同的SQL语句读取数据库,这段时间内,事务B

Mysql InnoDB 数据更新导致锁表

一.数据表结构 CREATE TABLE `jx_attach` ( `attach_id` int(11) NOT NULL AUTO_INCREMENT, `feed_id` int(11) DEFAULT NULL , `attach_name` varchar(255) NOT NULL, `cycore_file_id` varchar(255) DEFAULT NULL , `attach_size` bigint(20) NOT NULL DEFAULT '0', `complet

MySQL innodb中各种SQL语句加锁分析

概要 Locking read( SELECT ... FOR UPDATE or SELECT ... LOCK IN SHARE MODE),UPDATE以及DELETE语句通常会在他扫描的索引所有范围上加锁,忽略没有用到索引的那部分where语句.举个例子: CREATE TABLE `test` ( `id` int(11) NOT NULL DEFAULT '0', `name` varchar(10) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE

MySQL -- innodb中cardinality是如何统计的

cardinality是放在mysql存储引擎层进行的.采用的是采样取值.在innodb存储引擎中,cardinality统计信息的更新发生在两个操作中:insert和update 更新策略为:-表中1/16的数据发生过变化-stat_modified_counter>2000 000 000 (stat_modified_counter是innodb存储引擎中的一个计数器) 默认Innodb存储引擎对8个叶子节点进行采样.受参数innodb_stats_sample_pages影响. 当执行语

Mysql中那些锁机制之InnoDB

我们知道mysql在曾经.存储引擎默认是MyISAM.可是随着对事务和并发的要求越来越高,便引入了InnoDB引擎.它具有支持事务安全等一系列特性. InnoDB锁模式 InnoDB实现了两种类型的行锁. 共享锁(S):同意一个事务去读一行,阻止其它事务获得同样的数据集的排他锁. 排他锁(X):同意获得排他锁的事务更新数据,可是组织其它事务获得同样数据集的共享锁和排他锁. 能够这么理解: 共享锁就是我读的时候,你能够读,可是不能写.排他锁就是我写的时候.你不能读也不能写.事实上就是MyISAM的

从一个死锁看mysql innodb的锁机制

背景及现象 线上生产环境在某些时候经常性的出现数据库操作死锁,导致业务人员无法进行操作.经过DBA的分析,是某一张表的insert操 作和delete操作发生了死锁.简单介绍下数据库的情况(因为涉及到真实数据,这里做了模拟,不影响具体的分析和分析的结果.)假设存在如下2张表: Order 表的数据如下: Customer表的数据如下: Order和Customer 在实体关系上存在一个关联,即order实体拥有一个指向customer实体的指针.在数据库设计的时 候,order表的custome

[转]关于MYSQL Innodb 锁行还是锁表

关于mysql的锁行还是锁表,这个问题,今天算是有了一点头绪,mysql 中 innodb是锁行的,但是项目中居然出现了死锁,锁表的情况.为什么呢?先看一下这篇文章. 做项目时由于业务逻辑的需要,必须对数据表的一行或多行加入行锁,举个最简单的例子,图书借阅系统.假设 id=1 的这本书库存为 1 ,但是有 2 个人同时来借这本书,此处的逻辑为 Select   restnum from book where id =1 ;     -- 如果 restnum 大于 0 ,执行 update  U