SELECT * FROM t_bitfly;| | +------+-------+ | 아이디 | 값 | | +-------+ | |이 트랜잭션에서 처음으로 행을 읽었습니다. 업데이트가 이루어진 후 다른 트랜잭션에 제출된 데이터가 나타납니다. 일종의 환상읽기라고도 볼 수 있다.
설명과 함께
그럼 InnoDB가 팬텀리드를 피할 수 있다고 지적한 이유는 무엇일까요?
http://dev.mysql.com/doc/refman/5.0/en/innodb-record-level-locks.html
기본적으로 InnoDB는 REPEATABLE READ 트랜잭션 격리 수준에서 작동하며 innodb_locks_unsafe_for_binlog 시스템 변수는 비활성화되어 있습니다. 이 경우 InnoDB는 검색 및 인덱스 스캔에 다음 키 잠금을 사용하여 팬텀 행을 방지합니다(섹션 13.6.8.5,
"다음 키 잠금을 사용하여 팬텀 문제 방지") 준비된 이해는 격리 수준이 반복 가능한 읽기이고 innodb_locks_unsafe_for_binlog가 비활성화된 경우
search 및 검색 인덱스 중 next-keylock을 사용하여 팬텀 읽기를 피할 수 있다는 것입니다. 핵심은 InnoDB도 기본적으로 일반 쿼리에 다음 키 잠금을 추가합니까, 아니면 애플리케이션이 잠금 자체를 추가해야 합니까?입니다. 이 문장만 읽어도 InnoDB가 일반 쿼리에도 잠금을 추가한다고 생각할 수 있습니다. 그렇다면 직렬화(SERIALIZABLE)와 차이점은 무엇입니까?
MySQL 매뉴얼에는 또 다른 단락이 있습니다:
13.2.8.5 Next-Key 잠금을 사용하여 PhantomProblem 방지(http://dev.mysql.com/doc/refman/5.0/en/innodb-next-key- locking.html)
팬텀을 방지하려면
next-key라는 알고리즘을 사용하세요.
locking은 인덱스 행 잠금과 간격 잠금을 결합합니다.InnoDB다음 키 잠금을 사용하여 애플리케이션에서 고유성 검사를 구현할 수 있습니다. 공유 모드에서 데이터를 읽었지만 행에 대한 중복이 표시되지 않는 경우 insert를 사용하면 행을 안전하게 삽입하고 다음 키 잠금이 설정되어 있음을 알 수 있습니다.
읽기 중 행의 성공 또는 행의 중복을 삽입하는 동안 누군가가 의미하는 것을 방지합니다. 따라서 다음 키 잠금을 사용하면 테이블에 존재하지 않는 항목을 "잠글" 수 있습니다.
제가 이해한 바에 따르면 InnoDB는 다음을 제공합니다. 키 잠금을 사용할 수 있지만 애플리케이션이 자체적으로 잠궈야 합니다. 매뉴얼에 예시가 나와 있습니다:
SELECT * FROM child WHERE id> 100 FOR UPDATE;
这样，InnoDB会给id大于100的行（假如child表里有一行id为102），以及100-102，102+的gap都加上锁。
可以使用show engine innodb status来查看是否给表加上了锁。
再看一个实验，要注意，表t_bitfly里的id为主键字段。
实验4-3：
Session A |
Session B |
start transaction ; |
start transaction ; |
SELECT * FROM t_bitfly
WHERE id<=1
FOR UPDATE;
| +------+-------+
| | id | value |
| +------+-------+
| | 1 |a |
| +------+-------+ |
|
| |
INSERT INTO t_bitfly VALUES (2, 'b');
| Query OK, 1 row affected |
SELECT * FROM t_bitfly;
| +------+-------+
| | id | value |
| +------+-------+
| | 1 |a |
| +------+-------+ |
|
|
INSERT INTO t_bitfly VALUES (0, '0');
| (waiting for lock ...
| then timeout) ERROR 1205 (HY000):Lock wait timeout exceeded;
|try restarting transaction |
SELECT * FROM t_bitfly;
| +------+-------+
| | id | value |
| +------+-------+
| | 1 |a |
| +------+-------+ |
|
|
COMMIT; |
SELECT * FROM t_bitfly;
| +------+---------+
| | 아이디 | 가치 |
| +------+---------+
| | 1 |a |
| +------+-------+ |
|
id
첨부된 참고 사항:
MySQL 매뉴얼의 반복 읽기 잠금에 대한 자세한 설명:
http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html#isolevel_repeatable-read
읽기 잠금의 경우(SELECT with FOR
UPDATE or LOCK IN SHARE MODE),UPDATE,
and DELETE statements, locking depends on whether the statement uses
a unique index with a unique search condition, or a range-type search condition. For a unique index with a unique search condition, InnoDB locks
only the index record found, not the gap before it. For other search conditions, InnoDB 잠금
스캔된 인덱스 범위, 갭 잠금 또는 다음 키(갭 + 인덱스 레코드) 잠금을 사용하여 범위에 포함된 갭에 다른 세션이 삽입되는 것을 차단합니다.
일관성 읽기 및 커밋된 읽기, 먼저 실험을 살펴보세요.
실험 4-4:
세션 A |
세션 B |
거래 시작 ; |
거래 시작 ; |
SELECT * FROM t_bitfly;
| +------+---------+
| | 아이디 | 가치 |
| +------+---------+
| | 1 |a |
| +------+-------+ |
|
| |
INSERT INTO t_bitfly 값 (2, 'b'); |
| |
COMMIT; |
SELECT * FROM t_bitfly;
| +------+---------+
| | 아이디 | 가치 |
| +------+---------+
| | 1 |a |
| +------+-------+ |
|
SELECT * t_bitfly에서 공유 모드로 잠금;
| +----+---------+
| | 아이디 | 가치 |
| +----+---------+
| | 1 |a |
| | 2 |b |
| +----+-------+ |
|
SELECT * FROM t_bitfly FOR UPDATE;
| +----+---------+
| | 아이디 | 가치 |
| +----+---------+
| | 1 |a |
| | 2 |b |
| +----+-------+ |
|
SELECT * FROM t_bitfly;
| +----+---------+
| | 아이디 | 가치 |
| +----+---------+
| | 1 |a |
| +----+-------+ |
|
추가 참고 사항: 일반 읽기를 사용하면 일관된 결과를 얻을 수 있습니다. 잠긴 읽기를 사용하면 "최신" "커밋" 읽기 결과를 읽게 됩니다.
반복 읽기와 헌신 읽기는 그 자체로 모순됩니다. 동일한 트랜잭션에서 반복 읽기가 보장되면 다른 트랜잭션의 커밋이 표시되지 않으며 이는 커밋된 읽기를 위반합니다. 커밋된 읽기가 보장되면 이전 두 읽기의 결과가 일치하지 않아 반복 읽기가 위반됩니다.
InnoDB는 이러한 메커니즘을 제공한다고 할 수 있습니다. 기본 반복 읽기 격리 수준에서는 잠긴 읽기를 사용하여 최신 데이터를 쿼리할 수 있습니다.
http://dev.mysql.com/doc/refman/5.0/en/innodb-contant-read.html
데이터베이스의 "최신" 상태를 보려면 READ COMMITTED 격리 중 하나를 사용해야 합니다. 레벨 또는 잠금 읽기:
SELECT * FROM t_bitfly LOCK IN SHARE MODE;
------
3. 요약
결론: MySQL InnoDB 트랜잭션의 기본 격리 수준은 반복 가능한 읽기이며 그렇지 않습니다. 팬텀 판독을 방지하려면 애플리케이션에서 잠금 판독을 사용하여 이를 보장해야 합니다. 이 잠금 수준에 사용되는 메커니즘은 다음 키 잠금입니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
