精华内容
下载资源
问答
  • 共享锁和排他锁

    千次阅读 2013-10-16 16:09:10
    共享锁(S锁): 如果事务T对数据A加上共享锁后,则其他事务只能对A再加共享锁,不能加排他锁。获准共享锁的事务只能读数据,不能修改数据。 排他锁(X锁): 如果事务T对数据A加上排他锁后,则其他事务不能再对A...

    共享锁(S锁):共享 (S) 用于不更改或不更新数据的操作(只读操作),如 SELECT 语句。

    如果事务T对数据A加上共享锁后,则其他事务只能对A再加共享锁,不能加排他锁。获准共享锁的事务只能读数据,不能修改数据。


    排他锁(X锁):用于数据修改操作,例如 INSERT、UPDATE 或 DELETE。确保不会同时同一资源进行多重更新。

    如果事务T对数据A加上排他锁后,则其他事务不能再对A加任任何类型的封锁。获准排他锁的事务既能读数据,又能修改数据。


    简要说明为什么会发生死锁?解决死锁的主要方法是什么?
    若干事务相互等待释放封锁,就陷入无限期等待状态,系统就进入死锁


    解决死锁的方法应从预防和解除的两个方面着手:
    (1)死锁的预防方法:
    a、要求每一个事务必须一次封锁所要使用的全部数据(要么全成功,要么全不成功)
    b、规定封锁数据的顺序,所有事务必须按这个顺序实行封锁。
    (2)允许死锁发生,然后解除它,如果发现死锁,则将其中一个代价较小的事物撤消,回滚这个事务,并释放此事务持有的封锁,使其他事务继续运行。

    oracle:

    共享锁

    LOCK TABLE 表 IN SHARE MODE ;


    排他锁:

    LOCK TABLE 表 IN EXCLUSIVE MODE ;


    加锁后其它人不可操作,直到加锁用户解锁,用commit或rollback解锁



    行排他锁不阻止其他Session申请表共享锁和其他行的排他锁,但阻止申请表排他锁和锁定行的任何锁。
    表排他锁阻止其他Session的申请的所有锁。
    表共享锁不阻止其他Session申请行排他锁和表共享锁,但阻止申请表排他锁。


    一道相关的试题:
    User SCOTT executes the following command on the EMP table but has not issued COMMIT,ROLLBACK, or any data definition language (DDL)ommand:
    SQL> SELECT job FROM emp WHERE job='CLERK' FOR UPDATE OF empno;
    SCOTT has opened another session to work with the database. Which three operations would wait when issued in SCOTT's second session?(Choose three.)
    A. LOCK TABLE emp IN SHARE MODE;(阻止申请行的共享锁)
    B. LOCK TABLE emp IN EXCLUSIVE MODE;(阻止申请表的排他锁)
    C. DELETE FROM emp WHERE job='MANAGER';
    D. INSERT INTO emp(empno,ename) VALUES(1289,'Dick');
    E. SELECT job FROM emp WHERE job='CLERK' FOR UPDATE OF empno;(阻止申请行的排他锁)
    SELECT …… FROM …… FOR UPDATE 语句申请的是相应行的排他锁以及行所在表的共享锁。

    上题答案给的是A、B、E



    展开全文
  • Mysql共享锁, 排他锁意向锁的简单总结共享锁(Share Lock)排他锁(Exclusive Lock)意向锁(Intent Lock)InnoDB的两种表意向锁加锁过程说明各锁之间兼容详情表 共享锁(Share Lock) 共享锁又称读锁, 缩写(S)锁. 共享锁...

    共享锁(Share Lock)

    1. 共享锁又称读锁, 缩写(S)锁. 共享锁可以重复加, 但与排他锁(X)是有冲突的, 也就是只读
    2. 使用语法: SELECT … LOCK IN SHARE MODE;

    排他锁(Exclusive Lock)

    1. 排他锁又称写锁, 缩写(X)锁. 排他锁加了, 不允许加其它任何锁
    2. 使用语法: SELECT … FOR UPDATE;

    意向锁(Intent Lock)

    • 意向锁是表级锁, 在事务中, 用户申请加行锁时, 数据库会默认先申请意向锁, 也就是数据库自动处理意向锁的.

    InnoDB的两种表意向锁

    1. 意向共享锁(Intent Share Lock), 缩写(IS)锁
    2. 意向排他锁(Intent Exclusive Lock), 缩写(IX)锁

    加锁过程说明

    1. 未加意向锁时: 某 A用户事务中加了行锁, 之后某 B用户申请加表锁, 此时 B用户的请求在数据库内处理冲突的步骤, 首先判断是否已被其它事务加了表锁, 再判断表中是否有个行已被加了行锁, 遍历整张表
    2. 有意向锁时: A用户事务中申请意向共享锁, 成功后再申请行锁, 之后 B用户申请加表锁, 此时 B用户的请求在数据库内处理冲突的步骤, 首先判断是否已被其它事务加了表锁, 然后会发现已有意向共享锁锁住了某个行, B进入阻塞, 直到 A释放指定行锁
    • 能看出未加意向锁时, 可能会有整表遍历, 导致加锁的性能损失会很严重

    各锁之间兼容详情表

    -SXISIX
    S兼容冲突兼容冲突
    X冲突冲突冲突冲突
    IS兼容冲突兼容兼容
    IX冲突冲突兼容兼容

    如果您觉得有帮助,欢迎点赞哦 ~ 谢谢!!

    展开全文
  • Mysql共享锁、排他锁、悲观锁、乐观锁及其使用场景 一、相关名词 |--表级锁(锁定整个表) |--页级锁(锁定一页) |--行级锁(锁定一行) |--共享锁(S锁,MyISAM 叫做读锁) |--排他锁(X锁,MyISAM 叫做写锁...

    Mysql共享锁、排他锁、悲观锁、乐观锁及其使用场景

    一、相关名词

    |--表级锁(锁定整个表)

    |--页级锁(锁定一页)

    |--行级锁(锁定一行)

    |--共享锁(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执行

    end if

     

    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 被加锁,比如叫lockA,T2运行,再对 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 tran

         select * from table lock in share mode

         update table set column1='hello'

    T2:begin tran

         select * from table lock in share mode

         update table set column1='world'

     

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

     

    例5:-------------------------------------------------------------------------------------------------------------------------------------

    T1:begin tran

         update table set column1='hello' where id=10

    T2:begin tran

         update 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 tran

         select * from table for update

         update table set column1='hello'

    T2:begin tran

         select * from table for update

         update table set column1='world'

     

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

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

     

    例7:-------------------------------------------------------------------------------------------------------------------------------------

    T1:begin tran

         select * from table [加更新锁操作]

         update table set column1='hello'

    T2:begin tran

         select * from table [加更新锁操作]

         update table set column1='world'

     

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

     

    后面还有意向锁和计划锁:

    • 计划锁,和程序员关系不大,就没去了解。
    • 意向锁(innodb特有)分意向共享锁和意向排他锁。
      • 意向共享锁:表示事务获取行共享锁时,必须先得获取该表的意向共享锁;
      • 意向排他锁:表示事务获取行排他锁时,必须先得获取该表的意向排他锁;

    我们知道,如果要对整个表加锁,需保证该表内目前不存在任何锁。

    因此,如果需要对整个表加锁,那么就可以根据:检查意向锁是否被占用,来知道表内目前是否存在共享锁或排他锁了。而不需要再一行行地去检查每一行是否被加锁。

     

    四、乐观锁与悲观锁

    首先说明,乐观锁和悲观锁都是针对读(select)来说的。

    案例:

    某商品,用户购买后库存数应-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  

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

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

    • 悲观锁实际使用了排他锁来实现(select **** for update)。文章开头说到,innodb加行锁的前提是:必须是通过索引条件来检索数据,否则会切换为表锁。

      因此,悲观锁在未通过索引条件检索数据时,会锁定整张表。导致其他程序不允许“加锁的查询操作”,影响吞吐。故如果在查询居多的情况下,推荐使用乐观锁。

      加锁的查询操作”:加过排他锁的数据行在其他事务中是不能修改的,也不能通过for updatelock in share mode的加锁方式查询,但可以直接通过select ...from...查询数据,因为普通查询没有任何锁机制
    • 乐观锁更新有可能会失败,甚至是更新几次都失败,这是有风险的。所以如果写入居多,对吞吐要求不高,可使用悲观锁。

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

    如果喜欢本文,请关注公众号:开猿笔记,里面会有持续更新噢!

    在这里插入图片描述

    展开全文
  • 前言: 最怕面试官问到一大堆的锁概念了,表锁、页锁、行锁,排它锁、共享... 本文就着示例把InnoDB中的行锁的两种标准实现:共享锁和排它锁分析一下 准备: 1)笔者新建了张表(实际是copy的其他表),city...

    前言:

        最怕面试官问到一大堆的锁概念了,表锁、页锁、行锁,排它锁、共享锁...

        有关于锁的概念实在太多了,而我们在实际使用中使用到的又太少。很少有专门去写特定类型的锁实现,一般都是数据库默认帮我们做了相应的锁动作。

        本文就着示例把InnoDB中的行锁的两种标准实现:共享锁和排它锁分析一下

     

    准备:

        1)笔者新建了张表(实际是copy的其他表),city_copy表,主键为ID,自增长模式,默认从1开始。表创建SQL如下:

    CREATE TABLE `city_copy`  (
      `ID` int(11) NOT NULL AUTO_INCREMENT,
      `Name` char(35) CHARACTER SET latin1 COLLATE latin1_swedish_ci NOT NULL DEFAULT '',
      `CountryCode` char(3) CHARACTER SET latin1 COLLATE latin1_swedish_ci NOT NULL DEFAULT '',
      `District` char(20) CHARACTER SET latin1 COLLATE latin1_swedish_ci NOT NULL DEFAULT '',
      `Population` int(11) NOT NULL DEFAULT 0,
      PRIMARY KEY (`ID`) USING BTREE,
      INDEX `CountryCode`(`CountryCode`) USING BTREE
    ) ENGINE = InnoDB AUTO_INCREMENT = 4080 CHARACTER SET = latin1 COLLATE = latin1_swedish_ci ROW_FORMAT = Dynamic;

        2)有关于InnoDB事务和锁记录的几张表

            information_schema.INNODB_TRX:事务信息表

            information_schema.INNODB_LOCKS:锁信息表

            information_schema.INNODB_LOCK_WAITS:锁等待信息表

     

    1.共享锁事务之间的读取

        1)session1(共享锁)

    set autocommit=0; ##首先就是关闭自动提交
    select * from city where id < 4 lock in share mode; ##以共享模式读取数据
    
    select * from information_schema.INNODB_TRX; ##查询事务信息

        查询事务结果值:

        可以看到,当前SQL执行完成之后存在已经RUNNING(运行中)的事务,锁定记录数为4行

     

        2)session2(共享锁)

        与session1执行相同的动作

    set autocommit=0; ##首先就是关闭自动提交
    select * from city where id < 4 lock in share mode; ##以共享模式读取数据
    
    select * from information_schema.INNODB_TRX; ##查询事务信息

        结果就是:出现两条RUNNING事务记录,两个select语句分别都执行成功,获取到结果值

        两个session分别执行commit之后,运行中的事务信息消息。说明事务结束。

     

        总结:共享锁与共享锁之间是相互兼容的。

     

    2.共享锁与排它锁的事务示例

        1)session1(共享锁)

    set autocommit=0; ##首先就是关闭自动提交
    select * from city where id < 4 lock in share mode; ##以共享模式读取数据
    
    select * from information_schema.INNODB_TRX; ##查询事务信息

        session1执行共享锁读取方式,结果与1相同,不再展示

     

        2)session2(排它锁)

    set autocommit=0; ##首先就是关闭自动提交
    select * from city where id < 4 for update; ##以排它锁的方式读取
    select * from information_schema.INNODB_TRX; ##查询事务信息
    
    // res 事务结果值如下
    trx_id	trx_state	trx_started	trx_requested_lock_id	trx_wait_started	trx_weight	trx_mysql_thread_id	trx_query	trx_operation_state	trx_tables_in_use	trx_tables_locked	trx_lock_structs	trx_lock_memory_bytes	trx_rows_locked	trx_rows_modified	trx_concurrency_tickets	trx_isolation_level	trx_unique_checks	trx_foreign_key_checks	trx_last_foreign_key_error	trx_adaptive_hash_latched	trx_adaptive_hash_timeout	trx_is_read_only	trx_autocommit_non_locking
    462611	LOCK WAIT	2019-12-28 18:01:58	462611:50:5:2	2019-12-28 18:01:58	2	9	select * from city where id < 4 for update	starting index read	1	1	2	1136	1	0	0	REPEATABLE READ	1	1		0	0	0	0
    284711444560536	RUNNING	2019-12-28 18:01:38			2	10	select * from information_schema.INNODB_TRX		0	1	2	1136	4	0	0	REPEATABLE READ	1	1		0	0	0	0

        根据事务结果值可以看到,与之前的状态有所不同

        id=284711444560536的事务是session1的共享锁事务;

        id=462611的事务是session中的排它锁事务,目前是锁等待状态(表现形式就是目前获取不到select结果值,一直在转圈执行),这个会一直等待session1锁释放或者session2锁超时时候回滚

     

        总结:共享锁与排他锁是互不兼容的。

        读者也可以试试,先执行session2再执行session1,结果值也是互不兼容的。

     

    总结:

        1.我们首先需要记住的是:共享锁和排它锁都是行锁类型,所以上述的例子都是锁定id <4的这些数据行,如果两个session锁定的是不同的行记录,那么就不存在兼不兼容的问题了。

        2.排它锁的获取方式除了上述例子中的select ... for update,还有就是update 、delete操作

        3.共享锁与共享锁之间是相互兼容的

        4.共享锁与排它锁之间是互不兼容的

     

    参考:MySQL技术内幕 InnoDB存储引擎

    展开全文
  • mysql共享锁、排他锁、意向锁

    千次阅读 2019-07-23 15:21:45
    1.意向排他锁共享锁与排他锁冲突 (锁住一行的写锁,其他...2.意向共享锁和共享锁兼容排他锁冲突 (锁住一行的读锁,另一事务可获取该表的读锁,不可获取该表的写锁) 3.意向锁之间相互兼容 (行锁之间不冲突)
  • 本文通过代码实操讲解了如何使用 python 实现简单的共享锁和排他锁。 上篇文章回顾:记一次容量提升5倍的HttpDns业务Cache调优 共享锁和排它锁 1、什么是共享锁 共享锁又称为读锁。 从多线程的角度来讲,共享...
  • mysql共享锁和排它锁

    千次阅读 2019-04-09 14:43:14
    |--共享锁(S锁,MyISAM 叫做读锁) |--排他锁(X锁,MyISAM 叫做写锁) |--悲观锁(抽象性,不真实存在这个锁) |--乐观锁(抽象性,不真实存在这个锁)   二、InnoDB与MyISAM Mysql 在5.5之前默认使用 MyISAM...
  • 排他锁和共享锁

    千次阅读 2018-10-11 22:13:55
    出差的时候看见一个做BO的大牛写了这样一个SQL。select name from user for update,看的我是一脸懵逼,完全没有见过,好吧只能怪自己见识少了。...我们可以用商场的试衣间来做个比喻,商场里得每个试衣间都可供多个...
  • 共享锁浅析

    2019-10-21 22:23:04
    数据库大并发操作要考虑死锁锁的性能问题,看到网上大都语焉不详,在这里我想重新梳理一下共享锁,这里用T1代表数据库执行请求,T2代表另一个请求,T3,T4以此类推。 2 共享锁(s锁) T1: select * from table (请...
  • innodb锁-共享锁排他锁

    2019-01-13 16:27:05
    Shared and Exclusive Locks译称共享锁/排他锁,本文参考官方文档进行学习说明外加实验例子 数据库版本: SELECT VERSION(); ±-----------+ | version() | ±-----------+ | 5.6.34-log | ±-----------+ 数据库...
  • 一、共享锁 什么是共享锁:简单来说就是该锁锁定的资源只能进行读取,不能进行增删改操作,直到该锁释放。 example 1: 请求1:select * from tabletest 请求2:update tabletast set .... 数据库执行请求1的...
  • MySQL之共享锁与排它锁

    千次阅读 2021-03-09 19:08:04
    共享锁和排它锁
  • 又称读锁(S锁),共享锁不阻塞其他事务的读操作,但阻塞写操作,同一数据对象A可以共存多个共享锁,这被称为共享锁兼容。 当T1为数据对象A加上共享锁后,可以对A进行读操作,但不能进行写操作,并且T2可以再次对A加...
  • S锁:共享锁 加了S锁的记录,允许其他事务再加S锁,不允许其他事务再加X锁 select…lock in share mode X锁:排他锁 加了X锁的记录,不允许其他事务再加S锁或者X锁 select…for update 二.意向锁...
  • 的类型和兼容

    千次阅读 热门讨论 2016-09-11 21:02:37
    当我们使用单击版的系统时,根本不需要考虑并发量,但现在我们很多的系统都会有大量用户,我们就不得不面对并发,当出现并发...共享锁主要用于读写数据操作,它是非读占的,允许其他事务同时读取其锁定的资源,但不允
  • 的概述一. 为什么要引入多个用户同时对数据库的并发操作时会带来以下数据不一致的问题:丢失更新A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果,比如订票系统脏读A用户修改了...
  • 锁,很好理解,每个人都在自己的房屋上...共享锁(S锁),也叫读锁,当某行数据正在被读取时,其他进程修改 db2 事务的隔离 锁的这种机制都是为事务隔离来服务的,这里就不得不说下什么是事务,事务就是数据库管...
  • mysql锁机制之共享锁,排它锁

    千次阅读 2018-01-31 11:09:19
    我们知道mysql在以前,存储引擎默认是MyISAM,但是...共享锁(S):允许一个事务去读一行,阻止其他事务获得相同的数据集的排他锁。 排他锁(X):允许获得排他锁的事务更新数据,但是组织其他事务获得相同数据集
  • 的概述  一. 为什么要引入  多个用户同时对数据库的并发操作时会带来以下数据不一致的问题:  丢失更新  A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果,比如订票...
  • 共享锁与排它锁区别

    千次阅读 2014-02-13 19:11:47
    共享锁【S锁】 又称读锁,若事务T对数据对象A加上S锁,则事务T可以读A但不能修改A,其他事务只能再对A加S锁,而不能加X锁,直到T释放A上的S锁。这保证了其他事务可以读A,但在T释放A上的S锁之前不能对A做任何修改。...
  • 消失的共享锁

    千次阅读 2011-10-13 00:54:04
    消失的共享锁 原文地址: http://sqlblog.com/blogs/paul_white/archive/2010/10/31/read-committed-shared-locks-and-rollbacks.aspx  译者: 在SQL SERVER中,不同事
  • 本文参考: ...有很多是转载合并过来。是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中,除传统的 计算资源(如CPU、RAM、I/O等)的争用以外,数据也是一种供许多用户共享的资源。如何保证
  • |--共享锁(S锁,MyISAM 叫做读锁) |--排他锁(X锁,MyISAM 叫做写锁) |--悲观锁(抽象性,不真实存在这个锁) |--乐观锁(抽象性,不真实存在这个锁) 二、InnoDB与MyISAM Mysql 在5.5之前默认使用 MyISAM 存储...
  • 的概述一. 为什么要引入多个用户同时对数据库 的并发操作时会带来以下数据不一致的问题:丢 失更新A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果,比如订票系统脏读A用户修 改...
  • |–共享锁(S锁,MyISAM 叫做读锁) |–排他锁(X锁,MyISAM 叫做写锁) |–悲观锁(抽象性,不真实存在这个锁) |–乐观锁(抽象性,不真实存在这个锁) 二、InnoDB与MyISAM Mysql 在5.5之前默认使用 MyISAM 存储...
  • 乐观锁和悲观都是为了解决并发控制问题, 乐观锁可以认为是一种在最后提交的时候检测冲突的手段,而悲观则是一种避免冲突的手段。 乐观: 是应用系统层面数据的业务逻辑层次上的(实际上并没有加锁,只...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 48,926
精华内容 19,570
关键字:

共享锁和共享锁可以兼容