MySQL 및 InnoDB의 공유 잠금 및 배타적 잠금을 설명하는 예

이 기사는 MySQL의 공유 잠금 및 독점 잠금에 대한 관련 지식을 제공하며 모든 사람에게 도움이 되기를 바랍니다.

공유 잠금

공유 잠금, S 잠금, 읽기 잠금 이 모두 그의 이름입니다.

그리고 나는 그에게 공유 읽기 잠금이라고 부르고 싶습니다.

공유(S) 잠금은 잠금을 보유한 트랜잭션이 읽을 수 있도록 허용합니다.

공유 잠금을 사용하면 잠금을 보유한 트랜잭션이 읽을 수 있습니다.

여기서 나눔은 읽기 나눔입니다.

즉, 행 수준이든 테이블 수준이든 특정 데이터에 공유 읽기 잠금이 설정되면 다른 트랜잭션은 계속해서 읽을 수 있지만(즉, 공유 읽기 잠금을 유지할 수 있음) 쓸 수 없습니다. 즉, 읽을 수 없습니다. 쓰기 상호 배제 .

그나저나 공유 잠금(shared read lock)을 추가하는 방법을 소개하겠습니다:

Up 테이블 수준 공유 잠금, 즉 테이블 수준 공유 읽기 잠금:

select  *  from table（表） lock in share mode ；

업스트림 수준 공유 잠금, that 행 수준 공유 읽기 잠금:

select  *  from table（表）where id = 10  
lock in share mode
 ；

간단히 말씀드리자면, InnoDB에서는 행 잠금을 사용하려는 경우 행 잠금만 사용하는 것이 아니라는 점에 유의하세요. 행 잠금의 트리거 조건을 다시 검토해 보겠습니다. 시작 부분) :

전용 잠금(Exclusive lock) 잠금)

전용 잠금, 쓰기 잠금, X 잠금은 모두 그의 이름입니다.

저는 그 사람을 독점 쓰기 잠금이라고 부르고 싶습니다.

배타적(X) 잠금은 잠금을 보유한 트랜잭션이 업데이트되거나 삭제되도록 허용합니다.

배타적(X) 잠금을 사용하면 잠금을 보유한 트랜잭션을 업데이트하거나 삭제할 수 있습니다.

독점적인 단어입니다. 농구를 해 본 적이 있나요? 저는 중학교 때 농구를 할 줄 몰랐어요. 공을 잡고 있으면 패스를 안 하더군요. 내 반 친구들은 나에게 당신이 너무 외롭다고 말했습니다.

네, 저는 매우 외롭습니다. 이 배타적 쓰기 잠금(독점 잠금)과 마찬가지로 매우 독특합니다.

트랜잭션이 특정 데이터에 배타적 쓰기 잠금(배타적 잠금)을 추가하면 현재 트랜잭션만 해당 데이터를 수정하거나 삭제할 수 있습니다.

다른 거래는 읽거나 쓸 수 없습니다. 이 잠금은 매우 고유하므로 다른 트랜잭션이 이를 활용할 수 있으려면 이 고유한 잠금이 모두 사용(해제)될 때까지 기다려야 합니다.

그래서 배타적 쓰기 잠금(exclusive lock)은 읽기와 쓰기에 상호 배타적이며 쓰기와 쓰기에 상호 배타적입니다.

그나저나 배타적 잠금(배타적 쓰기 잠금)을 추가하는 방법을 소개하겠습니다:

업 테이블 수준 배타적 잠금, 즉 테이블 수준 배타적 쓰기 잠금:

select * from table
 for update 
；

업스트림 수준 배타적 잠금, 즉 행 수준 독점 쓰기 잠금:

select * from table where id =10 
 for update
 ；

여기서 좀 더 설명하겠습니다. InnoDB에서는 행 잠금을 사용하려는 경우 행 잠금만 사용하는 것이 아닙니다. 행 잠금의 트리거 조건을 검토해 보겠습니다. 다시 (처음에 언급함):

위 SQL은 인덱스에 도달하고 id가 인덱스이기 때문에 행 수준에서 배타적 잠금을 얻을 수 있습니다.

---

아마도 이것을 보면 공유 잠금 및 독점 잠금에 대해 여전히 모호할 것입니다. 읽기-읽기 공유, 읽기-쓰기 상호 배제, 쓰기-쓰기 상호 배제 등이 무엇인지 대략적으로 알 수 있습니다.

그러므로 우리는 이 두 자물쇠를 다시 하나님의 관점에서 바라볼 필요가 있습니다,

red 거래 연산 1

blue 거래 연산 2

	공유 잠금(공유 읽기 잠금)	독점 잠금(독점 쓰기 잠금)
공유 잠금(공유 읽기 잠금)	예, 호환 가능, 함께 읽기	아니요, 호환되지 않습니다. 글을 쓰려면 공유 잠금이 사라질 때까지 기다려야 합니다. 독점적으로 잠겨 있어 다른 사람은 아무것도 할 수 없습니다
那么如果你看到这里，还是对 共享锁  & 排他锁还只是云里雾里。 那我只有动手了! 实战介绍，演示 所谓的读读共享、读写互斥、写写互斥 。 在演示读读共享、读写互斥、写写互斥前， 我必须点明一点！ 在这篇文章里面，我介绍了一些上 共享锁（共享读锁）、排他锁（独占写锁）的方式 。 但是 可以看到写的查询sql 都是后面加了东西的 ，  lock in share mode ，for update  .... 等。 所以我想点明的一点是，   如果是使用 普通的查询 ，是 什么锁都没上的！ 就好像平时我们经常写的 select * from table ； select * from table where age=18； select语句默认不会加任何锁类型 select语句默认不会加任何锁类型 select语句默认不会加任何锁类型 而排他锁，除了 select .... for update ,InnoDB引擎 默认的修改 、插入、删除（update,insert,delete）都是会给操作的相关数据 加 排他锁的 . 废话不多说，我们上才艺： 准备一些用于测试的数据。 建表： DROP TABLE IF EXISTS `user`; CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `age` int(11) NULL DEFAULT NULL, `sex` tinyint(1) NULL DEFAULT NULL, PRIMARY KEY (`id`) USING BTREE ) ENGINE = InnoDB AUTO_INCREMENT = 5 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic; SET FOREIGN_KEY_CHECKS = 1; 搞点模拟数据： （id主键索引） 第一个小实践： 我们不废话，我们直接上共享读锁， 看看是不是能 符合刚才我们的理论 读读共享，读写互斥！ 1. 我们先给id=3这数据上个 共享读锁： 2.基于当前状况， 我们再执行一下查询语句，也是使用共享读锁的： 3.那么也是基于当前情况，我们再执行一下使用排他写锁的查询语句，可以发现 读写互斥了： 4.验证下，我们查看当前是否存在事务在等待锁： 可以从结果中看出 事务请求id 34847在等待锁： 我们再查询一下，那些事务在使用锁， 可以从结果看出，34844事务在使用S锁，也就是共享读锁； 而34847事务 在使用 X锁， 也就是排他写锁（但是由于共享读锁先上了，所以读写互斥了），所以造成了34847事务 在等待锁。 5.那么如果我们一直不 COMMIT 共享读锁， 34847事务 会永无止息地等待锁吗？   那么肯定是不可能允许这种一直等待的场景的： 所以mysql会有个等待锁资源超时的机制，这种情况就会直接返回查询失败的结果。 根据第一个小实践，我们得出一个很明显的结论： 当某数据上了 共享读锁 S 时， 只允许其他事务上共享读锁 S， 因为读读共享； 不允许其他事务上 独占写锁 X（除非把这个共享读锁S 释放掉），因为读写互斥。 第二个小实践： 1.我们直接给某行数据上个排他写锁 X (注意我们的事务是没有执行COMMIT的) ： 2. 我们接下来去 通过共享读锁去获取数据，看看会发生什么？ 这就是 独占写锁 X 的 读写互斥、写写互斥 （写写互斥的场景就不展示了）. 再验证下，我们看下是不是存在事务在等待锁资源： 3. 독점 쓰기 잠금이 해제되지 않으면 다른 트랜잭션이 계속 대기하게 됩니까? 동일합니다. 쿼리 실패를 반환하기 위해 시간 초과가 발생할 때까지 기다립니다. 약간 연습을 추가합니다. 1 여전히 동일합니다. 먼저 COMMIT 없이 특정 데이터에 독점 쓰기 잠금을 부여합니다. 2. 일반 쿼리를 실행하고 다음을 선택합니다. 일반 Select 문도 정상적으로 얻어지는 것을 볼 수 있는데, 그 이유는 무엇입니까? 아까도 언급했으니까 소위 읽기-읽기 공유, 읽기-쓰기 상호 배제, 쓰기-쓰기 상호 배제는 모두 잠금 리소스에 대한 것입니다. 잠금 리소스 경쟁이 없으면 상호 배제 또는 상호 배제가 없어야 합니다. 추천 학습: mysql 비디오 튜토리얼

위 내용은 MySQL 및 InnoDB의 공유 잠금 및 배타적 잠금을 설명하는 예의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!