llm-wiki/raw/official-docs/mysql-innodb-transaction-isolation-official.md

title, source_type, url, archive_url, related_branches, related_projects, tags, created

title	source_type	url	archive_url	related_branches	related_projects	tags	created
official-doc / MySQL InnoDB Transaction Isolation Levels — REPEATABLE READ default, READ COMMITTED consistent-read & locking behavior	official-doc	https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html		feature-transaction-concurrency-contract	ca-skeleton	official-doc ca-skeleton persistence mysql transaction-isolation	2026-06-09

official-doc / MySQL InnoDB Transaction Isolation Levels

Layer: raw/official-docs/ — MySQL 8.0 공식 레퍼런스에서 InnoDB 의 4가지 격리 수준 (isolation level) 정의 및 기본값 verbatim 발췌.

Parent / 활용 branch

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-transaction-concurrency-contract	D3: ca-tmpl TransactionPort 의 isolation default = READ_COMMITTED 설정 근거. MySQL InnoDB 의 vendor default 는 REPEATABLE READ 이므로 "묵시적 vendor default 사용 금지" 정책의 직접 근거. READ COMMITTED 와 REPEATABLE READ 의 consistent-read / locking-read 시맨틱 차이를 vendor SSOT 로 확정.

출처 / Source

• 원본 URL: https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html
• 아카이브 URL: (미수집)
• 저자 / 조직: Oracle Corporation (MySQL 8.0 Reference Manual)
• 발행일: MySQL 8.0 문서 — 지속 갱신
• 마지막 확인일: 2026-06-09

왜 저장했는지 / Why archived

feature-transaction-concurrency-contract D3 에서 "isolation level default = READ_COMMITTED (PostgreSQL/MySQL 양쪽 동일 의미)" 로 결정했으나, MySQL InnoDB 의 vendor default 가 REPEATABLE READ 임을 vendor 공식 문서로 입증한 raw 가 없어 UNSUPPORTED_DECISION 로 라벨되었다. 이 페이지는 InnoDB READ COMMITTED vs REPEATABLE READ 의 consistent-read / locking-read 시맨틱을 MySQL 공식 레퍼런스에서 직접 확정하여 D3 의 vendor SSOT 근거로 보관한다.

핵심 인용 / Key quotes (verbatim, self-grep 통과)

[§ 도입부] "InnoDB offers all four transaction isolation levels described by the SQL:1992 standard: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, and SERIALIZABLE. The default isolation level for InnoDB is REPEATABLE READ."

[§ REPEATABLE READ] "This is the default isolation level for InnoDB. Consistent reads within the same transaction read the snapshot established by the first read. This means that if you issue several plain (nonlocking) SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other. See Section 17.7.2.3, "Consistent Nonlocking Reads"."

[§ REPEATABLE READ — locking reads] "For other search conditions, InnoDB locks the index range scanned, using gap locks or next-key locks to block insertions by other sessions into the gaps covered by the range. For information about gap locks and next-key locks, see Section 17.7.1, "InnoDB Locking"."

[§ READ COMMITTED] "Each consistent read, even within the same transaction, sets and reads its own fresh snapshot. For information about consistent reads, see Section 17.7.2.3, "Consistent Nonlocking Reads"."

[§ READ COMMITTED — locking reads] "For locking reads (SELECT with FOR UPDATE or FOR SHARE), UPDATE statements, and DELETE statements, InnoDB locks only index records, not the gaps before them, and thus permits the free insertion of new records next to locked records. Gap locking is only used for foreign-key constraint checking and duplicate-key checking."

[§ SERIALIZABLE] "This level is like REPEATABLE READ, but InnoDB implicitly converts all plain SELECT statements to SELECT ... FOR SHARE if autocommit is disabled. If autocommit is enabled, the SELECT is its own transaction. It therefore is known to be read only and can be serialized if performed as a consistent (nonlocking) read and need not block for other transactions. (To force a plain SELECT to block if other transactions have modified the selected rows, disable autocommit.)"

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
MYSQL-ISO-C1	MySQL InnoDB 의 기본(default) isolation level 은 REPEATABLE READ 이다	[§ 도입부] "The default isolation level for InnoDB is REPEATABLE READ."	official-vendor-doc	MySQL 8.0 InnoDB storage engine	PostgreSQL 의 기본 isolation level (PostgreSQL default 는 READ COMMITTED — 별도 vendor doc 필요). 다른 MySQL storage engine (MyISAM 등) 에는 적용 안 됨
MYSQL-ISO-C2	REPEATABLE READ 에서 consistent read (nonlocking SELECT) 는 트랜잭션 내 첫 번째 읽기가 만든 스냅샷을 이후 모든 읽기에서 재사용한다	[§ REPEATABLE READ] "Consistent reads within the same transaction read the snapshot established by the first read."	official-vendor-doc	MySQL 8.0 InnoDB REPEATABLE READ isolation level 의 nonlocking SELECT	locking read (SELECT ... FOR UPDATE / FOR SHARE) 에는 적용 안 됨 — locking read 는 최신 상태를 사용함. PostgreSQL REPEATABLE READ 의 스냅샷 타이밍과 동일함을 보장하지 않음
MYSQL-ISO-C3	REPEATABLE READ 에서 locking read / UPDATE / DELETE 는 range 조건일 때 gap lock 또는 next-key lock 을 사용해 삽입을 차단한다	[§ REPEATABLE READ — locking reads] "InnoDB locks the index range scanned, using gap locks or next-key locks to block insertions by other sessions into the gaps covered by the range."	official-vendor-doc	MySQL 8.0 InnoDB REPEATABLE READ, range-type search condition 의 locking read / DML	unique index + unique search condition 에서는 index record 만 lock (gap lock 없음). READ COMMITTED 에서는 gap lock 비활성화됨
MYSQL-ISO-C4	READ COMMITTED 에서 consistent read (nonlocking SELECT) 는 같은 트랜잭션 내에서도 각 읽기마다 새로운 스냅샷을 설정하고 읽는다	[§ READ COMMITTED] "Each consistent read, even within the same transaction, sets and reads its own fresh snapshot."	official-vendor-doc	MySQL 8.0 InnoDB READ COMMITTED isolation level 의 nonlocking SELECT	locking read 의 동작을 설명하지 않음. "fresh snapshot" 이 PostgreSQL statement-level snapshot 과 의미상 동일함을 직접 보장하지 않음
MYSQL-ISO-C5	READ COMMITTED 에서 locking read 는 gap lock 없이 index record 만 잠근다 — gap lock 은 FK 제약 검사와 duplicate-key 검사에만 사용된다	[§ READ COMMITTED — locking reads] "InnoDB locks only index records, not the gaps before them, and thus permits the free insertion of new records next to locked records. Gap locking is only used for foreign-key constraint checking and duplicate-key checking."	official-vendor-doc	MySQL 8.0 InnoDB READ COMMITTED 의 locking read (SELECT FOR UPDATE / FOR SHARE), UPDATE, DELETE	phantom row 문제가 발생할 수 있음 — gap lock 비활성화의 트레이드오프 (동 페이지 §READ COMMITTED 명시). SERIALIZABLE 에서는 이 동작이 달라짐
MYSQL-ISO-C6	SERIALIZABLE 은 REPEATABLE READ 와 유사하지만 autocommit 비활성 시 모든 plain SELECT 를 SELECT ... FOR SHARE 로 묵시 변환한다	[§ SERIALIZABLE] "This level is like REPEATABLE READ, but InnoDB implicitly converts all plain SELECT statements to SELECT ... FOR SHARE if autocommit is disabled."	official-vendor-doc	MySQL 8.0 InnoDB SERIALIZABLE, autocommit=0 환경	autocommit=1 환경에서는 SELECT 가 자체 트랜잭션으로 처리되어 동작이 다름. XA 트랜잭션 / deadlock 트러블슈팅 등 특수 상황에 주로 사용 (동 페이지 도입부 명시)

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:
  • MYSQL-ISO-C1: MySQL 8.0 InnoDB 의 vendor default isolation level 이 REPEATABLE READ 임 — ca-tmpl 이 "묵시적 vendor default 사용 금지 + READ_COMMITTED 명시 선언" 정책을 채택하는 직접 근거.
  • MYSQL-ISO-C4: READ COMMITTED 에서 nonlocking SELECT 가 매번 fresh snapshot 을 설정함 — 동일 트랜잭션 내 반복 읽기 시 다른 값이 보일 수 있음 (non-repeatable read 허용).
  • MYSQL-ISO-C5: READ COMMITTED 에서 locking read 가 index record 만 잠금 — gap lock 없어 deadlock 확률 낮음, 단 phantom row 가능.
  • MYSQL-ISO-C2, MYSQL-ISO-C3: REPEATABLE READ 의 스냅샷 재사용 + gap lock 동작 — ca-tmpl 이 REPEATABLE READ 를 write-heavy use case 에서 명시 선언 시 기대할 시맨틱.
• 이 자료가 증명하지 않는 것:
  • PostgreSQL 의 READ COMMITTED 시맨틱이 MySQL InnoDB 와 동일한지 (Postgres 는 statement-level snapshot — 별도 raw 필요).
  • ca-tmpl TransactionPort 구현체에서 실제로 READ COMMITTED 가 적용되는지 (locally-verified 단계 검증 필요).
  • Spring @Transactional(isolation = Isolation.READ_COMMITTED) 이 MySQL JDBC driver 를 통해 정확히 이 시맨틱으로 전달되는지 (Spring Framework + JDBC driver 동작 별도 검증 필요).
  • READ COMMITTED 가 항상 REPEATABLE READ 보다 성능이 좋은지 — 트레이드오프는 workload 특성에 따라 다름.
• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • ca-tmpl 의 TransactionPort adapter 에서 Isolation.READ_COMMITTED 가 실제로 JDBC connection 의 isolation level 로 전달됨을 integration test 로 확인.
  • PostgreSQL 에서 READ COMMITTED 의 statement-level snapshot 동작을 별도 Postgres 공식 raw 로 수집 + ca-tmpl 이 가정하는 시맨틱과 대조.

메모 / Notes

• D3 UNSUPPORTED_DECISION 해소를 위한 직접 근거: MYSQL-ISO-C1 이 "InnoDB default = REPEATABLE READ" 를 vendor SSOT 로 확정함. "PostgreSQL/MySQL 양쪽에서 READ_COMMITTED 가 동일 의미" 주장 중 MySQL 부분은 MYSQL-ISO-C4 + MYSQL-ISO-C5 로 시맨틱 확정됨. PostgreSQL 부분은 https://www.postgresql.org/docs/current/transaction-iso.html raw 별도 수집 필요.
• READ COMMITTED 의 phantom row 허용 트레이드오프는 ca-tmpl write-heavy use case 설계 시 고려 필요 — MYSQL-ISO-C5 의 "phantom row problems may occur" 원문 확인.
• REPEATABLE READ 와 READ COMMITTED 의 deadlock 확률 차이는 동 페이지 §READ COMMITTED 예시 (x-lock acquire/release 패턴)에서 직접 설명됨 — 이 원문을 wiki/concepts/ 추출 시 포함 권장.

Related / 관련

• 같은 주제 PostgreSQL 공식 문서 (미수집): https://www.postgresql.org/docs/current/transaction-iso.html — D3 의 "양쪽 동일 의미" 주장 완결에 필요
• raw/official-docs/spring-tx-management-reference — Spring Framework @Transactional(isolation=...) 와의 연결
• raw/branch-notes/feature-transaction-concurrency-contract — 본 자료를 인용하는 branch (D3 UNSUPPORTED_DECISION 해소)