mysql间隙锁、表锁、行锁,读锁(共享锁)、写锁(排他锁),意向锁

1.间隙锁(Gap锁)

间隙锁是一个在索引记录之间的间隙上的锁。
例:

在这里插入图片描述

 间隙锁的作用:

保证某个间隙内的数据在锁定情况下不会发生任何变化。比如mysql默认隔离级别下的可重复读(RR)

当使用唯一索引来搜索唯一行的语句时,不需要间隙锁定。如下面语句的id列有唯一索引,此时只会对id值为10 的行使用记录锁
select * from t where id = 10 for update;注意:普通查询是快照读,不需要加锁。

如果上面语句中id列没有建立索引或者是非唯一索引时,则语句会产生产生间隙锁。

gap锁如何锁区间?

通过InnoDB中索引树的结构可以了解到:gap锁的关键就是锁住索引树的叶子结点之间的间隙,不让新的记录插入到间隙之中。

2.表锁 :

表锁就是锁住整张表,其他用户对该表的任何操作都受影响,具体影响取决于锁的形式。
MySQL的表锁有两种模式:表共享读锁(Table Read Lock)和表独占写锁(Table Write Lock):
 表共享读锁(Table Read Lock):不会阻塞其他用户对同一表的读请求,但会阻塞对同一表的写请求;
表独占写锁:会阻塞其他用户对同一表的读和写操作;

2.1表锁细节需要区分是MyISAM还是InnoDB

        MyISAM:        
                MyISAM在执行查询语句(SELECT)前,会自动给涉及的所有表加读锁,在执行更新操作(UPDATE、DELETE、INSERT等),会自动给涉及的表加写锁,这个过程并不需要用用户干预。

        InnoDB:
                必须显示加表锁语句
                注意:如果没有索引,InnoDB的行锁会升级为表锁,效果和表锁一样,锁住全部索引。

3.行锁(record lock)

行锁就是对具体的索引数据进行加锁,与表锁相比,粒度更小,减少竞争

行锁不是只能在一行上加锁,可以是若干行,可以是连续的,也可以是跳跃的

对于UPDATE、DELETE、INSERT语句,InnoDB会自动给涉及的数据集加排他锁(X);对于普通SELECT语句,InnoDB不会加任何锁。

4.共享锁(读锁)和排他锁(写锁)

InnoDB实现了以下两种类型的行锁:
        共享锁(s):共享锁又称为读锁,简称S锁,共享锁就是多个事务对于同一数据可以共享一把锁,都能访问到数据,但是只能读不能修改。

        排他锁(X):排他锁又称为写锁,简称X锁,排他锁就是不能与其他锁并存,如一个事务获取了一个数据行的排他锁,其他事务就不能再获取该行的其他锁,包括共享锁和排他锁,但是获取排他锁的事务是可以对数据进行读取和修改。

共享锁=读锁、排他锁=写锁,确切来说mysql没有读锁和写锁概念的,但是在实际应用中,读锁表示并发操作,写锁不支持并发,必须阻塞,因此可以这样划等号。但严格来说,在计算机概念中,不是所有的读锁都是支持并发的。

 事务可以通过以下语句显示给记录集加共享锁或排他锁:

共享锁(S):SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE

排他锁(X):SELECT * FROM table_name WHERE ...FOR UPDATE

InnoDB引擎默认的修改数据语句,update,delete,insert都会自动给设计到的数据加上排他锁,select语句默认不会加任何锁类型。

5.意向锁

意向锁是InnoDB自动加的,不需用户干预。

了允许行锁和表锁共存,实现多粒度锁机制,InnoDB还有两种内部使用的意向锁(Intention Locks),这两种意向锁都是表锁:

意向共享锁(IS):事务打算给数据行共享锁,事务在给一个数据行加共享锁前必须先取得该表的IS锁。
意向排他锁(IX):事务大Susan给数据行加排他锁,事务在给一个数据行加排他锁前必须先取得该表的IX锁。

事务在请求行锁中的共享锁和排他锁前,会先自动获得意向锁。

<think>好的,我现在需要回答用户关于MySQL中显式和隐式的区别及用法的问题。首先,我得回忆一下自己之前学过的相关知识,确保信息的准确性。 首先,显式和隐式的定义。显式是由用户或SQL语句明确请求的,比如使用SELECT ... FOR UPDATE或者LOCK TABLES这样的语句。而隐式是数据库引擎自动加上的,比如在插入操作时,为了保证事务的隔离性,InnoDB会自动加,不需要用户干预。这一点我记得引用里的内容提到过,隐式MySQL内部处理,不需要手动管理[^1]。 接下来,区别方面。用户需要知道两者的控制方式、使用场景、类型以及可见性。显式是用户主动控制的,比如事务中需要更新数据前先定,防止其他事务修改。而隐式是自动的,比如插入数据时,引擎自动加防止并发问题。类型的话,显式可能包括间隙锁等,而隐式通常是级的。可见性方面,显式可以通过performance_schema查看,而隐式在转换前可能不可见,但引用里提到在某些情况下隐式会转为显式,这时就能查到了[^2]。 然后使用场景。显式适合需要明确控制并发的情况,比如复杂的业务逻辑或避免死。隐式则用于常规操作,如普通的INSERT、UPDATE,由系统自动处理。这里要注意用户提到的快照和当前的区别,显式通常用于当前,比如SELECT ... FOR UPDATE,而快照可能依赖MVCC,不需要加[^3]。 还需要考虑事务类型。显式通常在显式事务中使用,比如用START TRANSACTION明确开始的事务。隐式可能在隐式事务中,比如自动提交模式下的单条语句。这点引用里提到显式通常用LOCK TABLES或者SELECT ... FOR UPDATE,而隐式自动处理[^3]。 另外,要提到两者的转换,比如当隐式遇到冲突时,可能会升级为显式,这样用户就能在performance_schema中看到了。这部分需要结合引用中的内容[^2]。 最后,总结区别的对比格,帮助用户一目了然。同时生成相关问题,比如如何监控隐式,显式的常见命令,隐式如何避免死等,这些都需要根据之前的内容来设计。 检查是否有遗漏的点,比如的兼容性、不同隔离级别下的现,但用户的问题主要区别和使用场景,可能不需要深入细节。不过要确保提到的点准确,比如显式的使用命令和隐式的自动管理,以及引用对应的来源。 现在把这些内容组织成结构清晰的回答,分点说明,并确保LaTeX格式正确,比如内公式用$...$,独立公式用$$...$$,但当前问题可能不需要数学公式,所以重点在格式和引用正确。</think>### MySQL显式与隐式的区别及用法 #### 一、核心区别 1. **控制方式** - **显式**:由用户通过SQL语句(如`SELECT ... FOR UPDATE`、`LOCK TABLES`)或事务命令主动声明。 - **隐式**:由MySQL引擎自动管理,例如插入数据时自动对索引加,无需用户干预[^2]。 2. **使用场景** - **显式**:适用于需要强制控制并发访问的场景,如避免脏、幻或实现悲观机制。 - **隐式**:用于常规数据操作(如`INSERT`、普通`UPDATE`),由InnoDB保证事务隔离性。 3. **类型与可见性** - **显式**:可通过`performance_schema.data_locks`直接查询,支持间隙锁等。 - **隐式**:默认不可见,仅在发生冲突时可能转换为显式(如二级索引插入时触发升级)。 4. **事务关联性** - **显式**:需在显式事务(`START TRANSACTION`)中配合使用,例如`SELECT ... FOR UPDATE`[^3]。 - **隐式**:自动绑定到隐式事务(如自动提交模式下的单条语句)。 #### 二、典型用法对比 | **特性** | 显式 | 隐式 | |------------------|---------------------------------|---------------------------------| | **控制权** | 用户主动声明 | 引擎自动管理 | | **可见性** | 可直接监控 | 冲突时转为显式才可见 | | **粒度** | 支持级、级、间隙锁 | 主要为 | | **典型语句** | `LOCK TABLES`, `FOR UPDATE` | `INSERT`, 普通`UPDATE` | | **事务要求** | 需显式事务支持 | 隐式/显式事务均可 | #### 三、应用示例 1. **显式** ```sql START TRANSACTION; SELECT * FROM orders WHERE id = 100 FOR UPDATE; -- 显式 UPDATE orders SET amount = 200 WHERE id = 100; COMMIT; ``` *用途*:确保其他事务无法修改`id=100`的,直到当前事务提交。 2. **隐式** ```sql INSERT INTO products (id, name) VALUES (101, 'Phone'); -- InnoDB自动对id=101加隐式 ``` *用途*:防止其他事务同时插入相同主键,保证唯一性。 #### 四、注意事项 1. **隐式的转换** 当隐式与显式冲突时(如另一个事务尝试修改被隐式定的),InnoDB会将其转换为显式,此时可通过`performance_schema`查看[^2]。 2. **死风险** 显式需谨慎设计加顺序,隐式因自动管理通常更安全,但批量操作仍可能引发竞争。 3. **隔离级别影响** 在`READ COMMITTED`级别下,显式可能仅定现有;在`REPEATABLE READ`级别下,可能附加间隙锁防止幻[^3]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值