数据库的锁:行级锁、表锁、乐观锁、悲观锁的实现原理

一、相关名词

表级锁(锁定整个表)
页级锁(锁定一页)
行级锁(锁定一行)
共享锁(S锁,MyISAM 叫做读锁)
排他锁(X锁,MyISAM 叫做写锁)
悲观锁(抽象性,不真实存在这个锁)
乐观锁(抽象性,不真实存在这个锁)

二、InnoDB与MyISAM

Mysql 在5.5之前默认使用 MyISAM 存储引擎,之后使用 InnoDB 。查看当前存储引擎:

show variables like ‘%storage_engine%‘;

MyISAM 操作数据都是使用的表锁,你更新一条记录就要锁整个表,导致性能较低,并发不高。当然同时它也不会存在死锁问题。

而 InnoDB 与 MyISAM 的最大不同有两点:一是 InnoDB支持事务;二是 InnoDB 采用了行级锁。也就是你需要修改哪行,就可以只锁定哪行。

在 Mysql 中,行级锁并不是直接锁记录,而是锁索引。索引分为主键索引和非主键索引两种,如果一条sql 语句操作了主键索引,Mysql 就会锁定这条主键索引;如果一条语句操作了非主键索引,MySQL会先锁定该非主键索引,再锁定相关的主键索引。

InnoDB 行锁是通过给索引项加锁实现的,如果没有索引,InnoDB 会通过隐藏的聚簇索引来对记录加锁。也就是说:如果不通过索引条件检索数据,那么InnoDB将对表中所有数据加锁,实际效果跟表锁一样。因为没有了索引,找到某一条记录就得扫描全表,要扫描全表,就得锁定表。

三、共享锁与排他锁

1.首先说明:数据库的增删改操作默认都会加排他锁,而查询不会加任何锁

共享锁:对某一资源加共享锁,自身可以读该资源,其他人也可以读该资源(也可以再继续加共享锁,即 共享锁可多个共存),但无法修改。要想修改就必须等所有共享锁都释放完之后。语法为:
select * from table lock in share mode

排他锁:对某一资源加排他锁,自身可以进行增删改查,其他人无法进行任何操作。语法为:
select * from table for update -- 增删改自动加了排他锁

2.下面援引例子说明(援自:http://blog.csdn.net/samjustin1/article/details/52210125):

这里用T1代表一个数据库执行请求,T2代表另一个请求,也可以理解为T1为一个线程,T2 为另一个线程。

例1:

T1: select * from table lock in share mode
(假设查询会花很长时间,下面的例子也都这么假设)

T2: update table set column1=‘hello‘

过程:

T1运行(并加共享锁)
T2运行
If T1还没执行完
T2等......
else锁被释放
T2执行
endif

T2 之所以要等,是因为 T2 在执行 update 前,试图对 table 表加一个排他锁,而数据库规定同一资源上不能同时共存共享锁和排他锁。所以 T2 必须等 T1 执行完,释放了共享锁,才能加上排他锁,然后才能开始执行 update 语句。

例2:

T1: select * from table lock in share mode

T2: select * from table lock in share mode

这里T2不用等待T1执行完,而是可以马上执行。

分析:
T1运行,则 table 被加锁,比如叫lockAT2运行,再对 table 加一个共享锁,比如叫lockB两个锁是可以同时存在于同一资源上的(比如同一个表上)。这被称为共享锁与共享锁兼容。这意味着共享锁不阻止其它人同时读资源,但阻止其它人修改资源。

例3:

T1: select * from table lock in share mode

T2: select * from table lock in share mode

T3: update table set column1=‘hello‘

T2 不用等 T1 运行完就能运行,T3 却要等 T1 和 T2 都运行完才能运行。因为 T3 必须等 T1 和 T2 的共享锁全部释放才能进行加排他锁然后执行 update 操作。

例4:(死锁的发生)

T1: begin transelect * from table lock in share modeupdate table set column1=‘hello‘

T2: begin transelect * from table lock in share modeupdate table set column1=‘world‘

假设 T1 和 T2 同时达到 select,T1 对 table 加共享锁,T2 也对 table 加共享锁,当 T1 的 select 执行完,准备执行 update 时,根据锁机制,T1 的共享锁需要升级到排他锁才能执行接下来的 update.在升级排他锁前,必须等 table 上的其它共享锁(T2)释放,同理,T2 也在等 T1 的共享锁释放。于是死锁产生了。

例5:

T1: begin tranupdate table set column1=‘hello‘ where id=10

T2: begin tranupdate table set column1=‘world‘ where id=20

这种语句虽然最为常见,很多人觉得它有机会产生死锁,但实际上要看情况

如果id是主键(默认有主键索引),那么T1会一下子找到该条记录(id=10的记录),然后对该条记录加排他锁,T2,同样,一下子通过索引定位到记录,然后对id=20的记录加排他锁,这样T1和T2各更新各的,互不影响。T2也不需要等。

如果id是普通的一列,没有索引。那么当T1对id=10这一行加排他锁后,T2为了找到id=20,需要对全表扫描。但因为T1已经为一条记录加了排他锁,导致T2的全表扫描进行不下去(其实是因为T1加了排他锁,数据库默认会为该表加意向锁,T2要扫描全表,就得等该意向锁释放,也就是T1执行完成),就导致T2等待。

死锁怎么解决呢?一种办法是,如下:

例6:

T1: begin transelect * from table for updateupdate table set column1=‘hello‘

T2: begin transelect * from table for updateupdate table set column1=‘world‘

这样,当 T1 的 select 执行时,直接对表加上了排他锁,T2 在执行 select 时,就需要等 T1 事物完全执行完才能执行。排除了死锁发生。但当第三个 user 过来想执行一个查询语句时,也因为排他锁的存在而不得不等待,第四个、第五个 user 也会因此而等待。在大并发情况下,让大家等待显得性能就太友好了。

所以,有些数据库这里引入了更新锁(如Mssql,注意:Mysql不存在更新锁)。

例7:

T1: begin transelect * from table (加更新锁)update table set column1=‘hello‘

T2: begin transelect * from table (加更新锁)update table set column1=‘world‘

更新锁其实就可以看成排他锁的一种变形,只是它也允许其他人读(并且还允许加共享锁)。但不允许其他操作,除非我释放了更新锁。T1 执行 select,加更新锁。T2 运行,准备加更新锁,但发现已经有一个更新锁在那儿了,只好等。当后来有 user3、user4...需要查询 table 表中的数据时,并不会因为 T1 的 select 在执行就被阻塞,照样能查询,相比起例6,这提高了效率。

后面还有意向锁和计划锁:意向锁即是:某行修改时,自动加上了排他锁,同时会默认给该表加意向锁,表示里面有记录正被锁定,这时,其他人就不可以对该表加表锁了。如果没有意向锁这个类似指示灯的东西存在,其他人加表锁之前就得扫描全表,查看是否有记录正被锁定,效率低下。而计划锁这些,和程序员关系不大,就没去了解了。

四、乐观锁与悲观锁

案例:

某商品,用户购买后库存数应-1,而某两个或多个用户同时购买,此时三个执行程序均同时读得库存为n,之后进行了一些操作,最后将均执行update table set库存数=n-1,那么,很显然这是错误的。

解决:

1.使用悲观锁(其实说白了也就是排他锁)

程序A在查询库存数时使用排他锁(select * from table where id=10 for update

然后进行后续的操作,包括更新库存数,最后提交事务。

程序B在查询库存数时,如果A还未释放排他锁,它将等待。

程序C同B……

2.使用乐观锁(靠表设计和代码来实现)

一般是在该商品表添加version版本字段或者timestamp时间戳字段

程序A查询后,执行更新变成了:
update table set num=num-1 where id=10 and version=23

这样,保证了修改的数据是和它查询出来的数据是一致的,而其他执行程序未进行修改。当然,如果更新失败,表示在更新操作之前,有其他执行程序已经更新了该库存数,那么就可以尝试重试来保证更新成功。为了尽可能避免更新失败,可以合理调整重试次数(阿里巴巴开发手册规定重试次数不低于三次)。

总结:对于以上,可以看得出来乐观锁和悲观锁的区别。

1.悲观锁使用了排他锁,当程序独占锁时,其他程序就连查询都是不允许的,导致吞吐较低。如果在查询较多的情况下,可使用乐观锁。

2.乐观锁更新有可能会失败,甚至是更新几次都失败,这是有风险的。所以如果写入较频繁,对吞吐要求不高,可使用悲观锁。

也就是一句话:读用乐观锁,写用悲观锁。

原文地址:https://www.cnblogs.com/windpoplar/p/11938432.html

时间: 2024-08-06 20:47:31

数据库的锁:行级锁、表锁、乐观锁、悲观锁的实现原理的相关文章

在mysql数据库中制作千万级测试表

在mysql数据库中制作千万级测试表 前言: 最近准备深入的学一下mysql,包括各种引擎的特性.性能优化.分表分库等.为了方便测试性能.分表等工作,就需要先建立一张比较大的数据表.我这里准备先建一张千万记录用户表. 步骤: 1 创建数据表(MYISAM方式存储插入速度比innodb方式快很多)   数据表描述 数据量:1千万 字段类型: id :编号 uname:用户名 ucreatetime: 创建时间 age:年龄 CREATE TABLE usertb(    id serial,   

Oracle锁表 行级锁 表级锁 行级锁

Oracle锁表  行级锁  表级锁 ---- 行被排他锁定 ----在某行的锁被释放之前,其他用户不能修改此行          ----使用 commit 或 rollback 命令释放锁 ----Oracle 通过使用 INSERT.UPDATE 和 SELECT-FOR UPDATE 语句自动获取行级锁 SELECT-FOR UPDATE 子句  ―在表的一行或多行上放置排他锁  ―用于防止其他用户更新该行 ―可以执行除更新之外的其他操作 ―select * from goods whe

[数据库事务与锁]详解五: MySQL中的行级锁,表级锁,页级锁

注明: 本文转载自http://www.hollischuang.com/archives/914 在计算机科学中,锁是在执行多线程时用于强行限制资源访问的同步机制,即用于在并发控制中保证对互斥要求的满足. 在数据库的锁机制中介绍过,在DBMS中,可以按照锁的粒度把数据库锁分为行级锁(INNODB引擎).表级锁(MYISAM引擎)和页级锁(BDB引擎 ). 行级锁 行级锁是Mysql中锁定粒度最细的一种锁,表示只针对当前操作的行进行加锁.行级锁能大大减少数据库操作的冲突.其加锁粒度最小,但加锁的

Mysql 的表级锁和行级锁

表级锁 MySQL表级锁分为读锁和写锁. 读锁 用法:LOCK TABLE table_name [ AS alias_name ] READ 释放锁使用UNLOCK tables.可以为表使用别名,如果一旦使用别名在使用的时候也必须采用别名.成功申请读锁的前提是当前没有线程对该表使用写锁,否则该语句会被阻塞.申请读锁成功后,其他线程也可以对该表进行读操作,但不允许有线程对其进行写操作,就算是当前线程也不允许.当锁住了A表之后,就只能对A表进行读操作,对其他表进行读操作会出现错误(tablena

【转】MySQL中的行级锁,表级锁,页级锁

在计算机科学中,锁是在执行多线程时用于强行限制资源访问的同步机制,即用于在并发控制中保证对互斥要求的满足. 在数据库的锁机制中介绍过,在DBMS中,可以按照锁的粒度把数据库锁分为行级锁(INNODB引擎).表级锁(MYISAM引擎)和页级锁(BDB引擎 ). 行级锁 行级锁是Mysql中锁定粒度最细的一种锁,表示只针对当前操作的行进行加锁.行级锁能大大减少数据库操作的冲突.其加锁粒度最小,但加锁的开销也最大.行级锁分为共享锁 和 排他锁. 特点 开销大,加锁慢:会出现死锁:锁定粒度最小,发生锁冲

web开发中的两把锁之数据库锁:(高并发--乐观锁、悲观锁)

这篇文章讲了 1.同步异步概念(消去很多疑惑),同步就是一件事一件事的做:sychronized就是保证线程一个一个的执行. 2.我们需要明白,锁机制有两个层面,一种是代码层次上的,如Java中的同步锁,典型的就是同步关键字synchronized ( 线    程级别的).另一个就是数据库层次上的,比较典型的就是悲观锁和乐观锁. 3.常见并发同步案例分析   附原文链接 http://www.cnblogs.com/xiohao/p/4385508.html 对于我们开发的网站,如果网站的访问

数据库的悲观锁、乐观锁

并发控制 并发情况下,需要做一些控制(一般是加锁),保证共享数据的一致性. 并发操作数据库时,需要给数据库中的数据加锁,确保数据库中数据的一致性. 数据库锁的常见分类 按使用方式来分:悲观锁.乐观锁 按锁级别来分:共享锁.排它锁(主要是这2种,当然还有其他的) 按锁粒度来分:行级锁.表级锁.页级锁 悲观锁  Pessimistic Lock 悲观的,假设是最坏的情况,认为其它线程一定会修改当前线程使用的数据库数据,当前线程一定要给使用的数据库数据加锁. 悲观锁只是个统称,并不是指某一种具体的锁.

php使用数据库的并发问题(乐观锁与悲观锁)

在php与数据库的交互中,如果并发量大,并且都去进行数据库的修改的话,就有一个问题需要注意.数据的锁问题.就会牵扯数据库的事务跟隔离机制 数据库事务依照不同的事务隔离级别来保证事务的ACID特性,也就是说事务不是一开启就能解决所有并发问题.通常情况下,这里的并发操作可能带来四种问题: 更新丢失:一个事务的更新覆盖了另一个事务的更新,这里出现的就是丢失更新的问题. 脏读:一个事务读取了另一个事务未提交的数据. 不可重复读:一个事务两次读取同一个数据,两次读取的数据不一致. 幻象读:一个事务两次读取

数据库乐观锁与悲观锁

前面说到了数据库的隔离级别,隔离性是数据库中数据有意义的条件之一,而不同的隔离级别,归根到底其实是在读和写的操作中对表.事务后者是表进行对应的锁定操作,所以下面简单总结下数据库的两种类型锁:乐观和悲观锁,很多是概念性的东西和个人理解,不足之处也请指正. 一.锁的概念 简单说说数据库锁的概念,和多线程中的锁类似,数据库中对数据的锁定其实也是保证数据同步的主要手段,它表现出来的是:并发下,线程之间对数据库数据的操作是单方的.而在数据库里面主要有两种锁手段保证这种并发下的线程单方面操作:悲观锁和乐观锁

[转]数据库并发控制 乐观锁,悲观锁

在数据库中,并发控制有乐观锁和悲观锁之间,什么时候用乐观锁比较好什么时候用悲观锁比较好? 实际生产环境里边,如果并发量不大,完全可以使用悲观锁定的方法,这种方法使用起来非常方便和简单.但是如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以就要选择乐观锁定的方法. 悲观锁假定其他用户企图访问或者改变你正在访问.更改的对象的概率是很高的,因此在悲观锁的环境中,在你开始改变此对象之前就将该对象锁住,并且直到你提交了所作的更改之后才释放锁.悲观的缺陷是不论是页锁还是行锁,加锁的时间可能会很长