트랜잭션 격리성 수준

1) 트랜잭션

 

(1) 트랜잭션이란

• DB 에서의 트랜잭션이란 데이터베이스에서 수행하는 작업의 논리적인 단위를 말하며, 하나의 트랜잭션은 데이터베이스에서 일련의 작업들을 포함하며 이러한 작업들은 모두 성공적으로 수행되거나 실패해야 한다. → All or Nothing 전략

 

(2) 트랜잭션의 4가지 특성 (ACID)

• DB에서의 트랜잭션은 아래의 4가지 특성을 지닌다.

 

(2-1) Atomicity (원자성)

• 트랜잭션은 논리적으로 하나의 실행 단위여야 하고 물리적으로 여러 개의 Statement로 구성되어 있다 하더라도 논리적인 단위로 묶일 수 있어야 한다.

 

• 하나의 실행 단위라면 두 개의 상태로 귀결되는데, 성공하거나 또는 실패하거나이다. (All or Nothing)

 

• 즉, 여러 개의 Statement로 작성되었다 하더라도 하나의 트랜잭션으로 묶인다면 한 트랜잭션 내에서 실행한 작업들은 하나의 작업으로 간주하고 모두 성공 또는 실패되어야 한다는 것이다. (부분 성공 / 부분 실패 없음)

 

(2-2) Consistency (일관성)

• 트랜잭션의 작업 처리 결과가 항상 일관성이 있어야 하며, 트랜잭션이 진행되는 동안에 데이터베이스가 변경되더라도 업데이트된 데이터베이스로 트랜잭션이 진행되는 것이 아니라, 처음에 트랜잭션을 진행하기 위해 참조한 데이터베이스로 진행된다.

 

(2-3) Isolation (격리성)

• 둘 이상의 트랜잭션이 동시에 실행되고 있을 경우, 어떤 하나의 트랜잭션이라도 다른 트랜잭션의 연산에 끼어들 수 없다.

 

• 수행 중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없다.

 

→ 즉, 동시에 실행되는 트랜잭션들이 서로 영향을 미치지 않도록 격리한다는 것이다.

 

(2-4) Durability (지속성)

• 트랜잭션이 성공적으로 완료되었을 경우, 그 결과는 데이터베이스에 영속적으로 저장, 반영되어야 한다. (COMMIT)

 

• 비록 트랜잭션이 실패되더라도 그 상태가 일관되게 유지되어야 한다. (ROLLBACK)

 

2) 트랜잭션 격리성 (Transaction Isolation)

• 트랜잭션의 특성 중 격리성에 대해 자세하게 알아보자!

 

• 위에서 살펴보았듯이, 격리성은 “실행 중인 트랜잭션의 중간 결과를 다른 트랜잭션이 접근할 수 없다.”라고 하였으나 막연하게 접근할 수 없다라기 보다는 일반적으로 접근 레벨이 존재하고 DB에 따라 설정이 가능하다.

 

• 이러한 격리성 접근 레벨은 강하게 처리할 수도 있고 반대로 약하게 처리할 수도 있다.

 

• 일단 격리성으로 인해 발생할 수 있는 문제점을 먼저 살펴본 다음 격리성 접근 레벨을 알아볼 예정이다.

 

(1) 격리성으로 인해 발생할 수 있는 문제

• 격리성으로 인해 발생할 수 있는 문제는 일반적으로 Dirty Read, Non-Repeatable Read, Phantom Read 3가지이다.

 

(1-1) Dirty Read

Dirty Read는 다른 트랜잭션에 의해 수정됐지만 아직 커밋되지 않은 데이터를 읽는 것을 말한다.

• 만약, Transaction_1이 정상처리되지 않고 Rollback 될 수도 있는데 이런 경우, 그 값을 이미 읽은 Transaction_2는 잘못된 값을 가지고 본인의 로직을 처리하는 상태에 놓이게 된다.

 

• 즉, Transaction_2는 데이터 무결성이 깨진 데이터를 사용하게 된다는 것이다.

 

(1-2) Non-Repeatable Read

Non-Repeatable Read는 한 트랜잭션 내에서 같은 Key를 가진 Row를 두 번 Read 하였는데 그 사이에 값이 변경되거나 삭제되어 결과가 다르게 나타나는 현상을 말한다.

• 즉, Transaction_2에서 특정 Row를 2번 Read 하는데 그 사이에 Transaction_1이 해당 Row를 Update하거나 Delete 후에 Commit 하게 되어 Transaction_2에서 다시 Read 하였을 때, 값이 다르게 나오는 것이다.

 

(1-3) Phantom Read

한 트랜잭션 내에서 같은 쿼리를 두 번 수행하였는데, 첫 번째 쿼리에서 없던 유령 레코드 (Phantom Record)가 두 번째 쿼리에서 나타나는 현상을 말한다.

• 즉, Transaction_2가 특정 조건으로 데이터를 검색하여 결과를 얻었으나 이 때, 다른 Transaction_1이 해당 조건의 데이터 일부를 추가/삭제하고 Commit 하게 되어 아직 끝나지 않은 Transaction_2가 해당 조건으로 데이터를 조회하면 Transaction_1에서 추가/삭제한 데이터가 함께 조회/누락 된다는 것이다.

 

• Phantom Read와 Non-Repeatable Read를 헷갈릴 수 있는데 Non-Repeatable Read는 1개의 Row의 데이터의 값이 변경되는 것이며 (Update 또는 Delete), Phantom Read는 다수의 건을 요청하는 것에 대해서 데이터의 값이 변경되는 것이다.

 

(2) DB에서 지정할 수 있는 격리성 수준 [격리성 접근 레벨]

• 그렇다면 이제 DataBase에서 제공하는 격리성 수준 (Transaction Isolation Level)에 대해서 알아보자.

 

• ANSI/ISO SQL 표준(SQL92)에서는 트랜잭션의 격리성과 동시 처리 성능 사이의 Trade-Off를 두고 격리성 접근 레벨을 4단계로 나누었다.

 

• 격리 수준이 높아질 수록 위에서 언급했던 격리성으로 인한 이슈는 적게 발생하지만 동시 처리 성능은 떨어지게 된다. (Trade-Off 관계)

 

• 또한, 트랜잭션이 발생하게 되면 DB 내부적으로 DB 락(DB Lock)이 걸리게 되는데 락에 대해서는 뒷 부분에서 다룰 예정이다.

 

• 참고로 DBMS 제품마다 내부적으로 격리성 접근 수준 or Lock 메커니즘은 다를 수 있으므로 필요할 시, 해당 DB의 Document 문서를 읽어보자

 

• 해당 내용은 MySQL을 통해 실습할 것이므로 아래의 SQL을 통해 실습용 테이블을 생성하고, 용이한 실습을 위해 별도의 제약 조건은 설정하지 않는다.

// 테이블 생성
CREATE TABLE EMP (
ID INT not null auto_increment,
NAME VARCHAR(100) not null,
JOB VARCHAR(30) not null,
primary key (ID));

// 초기 데이터 생성
insert into EMP values (1, "userA", 'Student');
insert into EMP values (2, "userB", 'Student');
insert into EMP values (3, "userC", 'Student');

[참고] 트랜잭션 격리 수준 조회 및 수정 (MariaDB)

// 트랜잭션 격리 수준 조회
show variables like 'tx_isolation';

// 트랜잭션 격리 수준 수정
set tx_isolation = 'READ-UNCOMMITTED’

// Autocommit 설정값 확인
show variables like 'autocommit%';

// Autocommit 끄기
SET AUTOCOMMIT = FALSE

• 추가적으로 격리성 수준 실습을 위해 미리 DB 세션을 2개 연결해놓도록 하고 Autocommit 기능은 끄도록 한다.

 

(2-1) Read Uncommitted - 커밋되지 않는 것을 읽음

트랜잭션에서 처리 중인, 아직 커밋되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용한다.

• 즉, 커밋하지 않은 데이터를 읽을 수 있다는 것이다.

 

• 발생 문제점 : Dirty Read, Non-Repeatable Read, Phantom Read

 

• 해당 설정은 정합성에 문제가 있기 때문에 권장하는 설정은 아니지만 다른 격리성 수준에 비해 동시 처리 성능은 가장 높다.

 

• 참고로 데이터를 읽거나 쓸 때 내부적으로 Lock이 사용되며 DBMS 마다 사용되는 Lock 메커니즘은 다를 수 있다.

# 실습 
[세션 1, 2 공통]
set tx_isolation = 'READ-UNCOMMITTED’
SET AUTOCOMMIT = FALSE
START TRNASACTION;

[세션 1]
INSERT INTO EMP VALUES (4, “Test”, “Student”);

[세션 2]
MariaDB [mysql]> SELECT * FROM EMP WHERE ID = 4;
+----+------+---------+
| ID | NAME | JOB     |
+----+------+---------+
|  4 | Test | Student |
+----+------+---------+
1 row in set (0.001 sec)

[세션 1]
ROLLBACK;

[세션 2]
MariaDB [mysql]> SELECT * FROM EMP WHERE ID = 4;
Empty set (0.000 sec)

• 이처럼 세션 1 트랜잭션에서 처리한 작업이 완료되지 않았음에도 불구하고 (Commit) 세션 2 트랜잭션에서 데이터를 읽을 수 있다.

 

• 위의 코드를 보면 세션 1 트랜잭션에서 처리한 작업이 세션 2 트랜잭션에서도 조회가 되기 때문에 세션 1에서 Rollback을 통해 이전으로 돌리게 되면 세션 2는 이전에 조회한 데이터를 가지고 비즈니스 로직을 수행하게 된다.

 

• 따라서, 위에서 언급했던 격리성으로 발생하는 문제 중 하나인 “Dirty Read” 현상이 발생한다.

 

(2-2) Read Committed - 커밋된 것을 읽음

트랜잭션이 커밋되어 확정된 데이터만 다른 트랜잭션이 읽도록 허용한다.

• 즉, 커밋이 완료된 데이터만 읽을 수 있다는 것이다.

 

• 발생 문제점 : Non-Repeatable Read, Phantom Read

 

• 커밋되지 않은 데이터에 대해서는 실제 DB 데이터가 아닌 UNDO 로그에 있는 이전 데이터를 가져오게 된다.

 

• Uncommitted Read 수준에 비해 동시 처리 성능은 떨어지나 Dirty Read가 발생할 가능성은 없다.

 

• 하지만 여전히 Non-Repeatable Read와 Phantom Read에 대해서는 발생할 가능성이 있다.

 

• 참고로 데이터를 읽거나 쓸 때 내부적으로 Lock이 사용되며 DBMS 마다 사용되는 Lock 메커니즘은 다를 수 있다.

 

[참고] UNDO 로그

• Mysql, MariaDB에서 사용되는 InnoDB 스토리지 엔진은 트랜잭션이 Rollback 될 가능성에 대비해 변경되기 전 레코드를 UNDO 공간에 백업해두고 실제 레코드 값을 변경한다.

 

• 이러한 변경 방식을 MVCC (Multi-Version Concurrency Control) 이라고 한다.

 

• 즉, Read-UnCommitted는 데이터 파일에서 데이터를 직접 읽어오며 Read-Committed는 데이터 파일이 커밋되지 않은 데이터일 경우 UNDO 로그에서 최신 UNDO 레코드를 읽어오는 것이다.

 

• 정리하자면 UNDO 로그는 “트랜잭션의 롤백 대비용”, “트랜잭션의 격리 수준을 유지하며 높은 동시성 제공” 용도로 사용된다.

# 실습 
[세션 1, 2 공통]
set tx_isolation = 'READ-COMMITTED';
SET AUTOCOMMIT = FALSE
START TRNASACTION;

[세션 2]
MariaDB [mysql]> SELECT * FROM EMP;
+----+-------+---------+
| ID | NAME  | JOB     |
+----+-------+---------+
|  1 | userA | Student |
|  2 | userB | Student |
|  3 | userC | Student |
+----+-------+---------+
3 rows in set (0.000 sec)

[세션 1]
UPDATE EMP SET NAME = ‘modified’ WHERE ID = 3;

[세션 2]
MariaDB [mysql]> SELECT * FROM EMP;
+----+-------+---------+
| ID | NAME  | JOB     |
+----+-------+---------+
|  1 | userA | Student |
|  2 | userB | Student |
|  3 | userC | Student |
+----+-------+---------+
3 rows in set (0.000 sec)

→ Dirty Read 현상은 발생하지 않음을 확인할 수 있다.

[세션 1]
COMMIT;

[세션 2]
MariaDB [mysql]> SELECT * FROM EMP;
+----+----------+---------+
| ID | NAME     | JOB     |
+----+----------+---------+
|  1 | userA    | Student |
|  2 | userB    | Student |
|  3 | modified | Student |
+----+----------+---------+
3 rows in set (0.000 sec)

• 이처럼 세션 1 트랜잭션에서 데이터가 수정되었지만 Commit이 안됐기 때문에 세션 2 트랜잭션에서는 수정된 데이터로 조회되지 않는다.

 

• 따라서, Dirty Read 문제는 해결되었지만 세션 2 트랜잭션은 EMP 테이블의 ID = 3번인 ROW를 두 번 SELECT 하는데 두 번째 SELECT을 하기 전에 세션 1 트랜잭션에서 해당 ROW를 수정하고 COMMIT 했기 때문에 세션 2 트랜잭션에서의 첫 번째 SELECT와 두 번째 SELECT의 결과가 다르게 나오는 Non-Repeatable Read 문제가 발생한다.

 

• 그 외에도 세션 1 트랜잭션에서 UPDATE문이 아닌 INSERT문을 사용하였다면 Phantom Read 현상 또한 발생하게 된다.

 

(2-3) Repeatable Read – 반복적으로 읽음

트랜잭션 내에서 삭제, 변경에 대해서는 UNDO 로그에 넣어두고, 앞서 발생한 트랜잭션에 대해서는 실제 데이터가 아닌 UNDO 로그에 있는 백업 데이터를 읽도록 한다.

• 따라서, 값의 변경에 대해서 일정한 값으로 처리할 수 있기 때문에 삭제와 수정에 대해서 트랜잭션 내에 불일치를 가져오던 Non-Repeatable Read 문제를 해결할 수 있다.

 

• 즉, 트랜잭션 내에서 한 번 조회한 데이터를 반복해서 조회해도 같은 데이터가 조회된다는 것이다.

 

• 발생 문제점 : Phantom Read

 

• 참고로 데이터를 읽거나 쓸 때 내부적으로 Lock이 사용되며 DBMS 마다 사용되는 Lock 메커니즘은 다를 수 있다.

# 실습 
[세션 1, 2 공통]
set tx_isolation = 'REPEATABLE-READ’
SET AUTOCOMMIT = FALSE
START TRNASACTION;

[세션 2]
MariaDB [mysql]> SELECT * FROM EMP;
+----+-------+---------+
| ID | NAME  | JOB     |
+----+-------+---------+
|  1 | userA | Student |
|  2 | userB | Student |
|  3 | userC | Student |
+----+-------+---------+
3 rows in set (0.000 sec)

[세션 1]
UPDATE EMP SET NAME = ‘modified’ WHERE ID = 3;
COMMIT;

[세션 2]
MariaDB [mysql]> select * from emp;
+----+-------+---------+
| ID | NAME  | JOB     |
+----+-------+---------+
|  1 | userA | Student |
|  2 | userB | Student |
|  3 | userC | Student |
+----+-------+---------+
3 rows in set (0.000 sec)

[세션 1]
INSERT INTO EMP VALUES (4, “Test”, “Student”);
COMMIT;

[세션 2]
MariaDB [mysql]> select * from emp;
+----+-------+---------+
| ID | NAME  | JOB     |
+----+-------+---------+
|  1 | userA | Student |
|  2 | userB | Student |
|  3 | userC | Student |
+----+-------+---------+
3 rows in set (0.000 sec)

[세션 2]
COMMIT;
MariaDB [mysql]> select * from emp;
+----+----------+---------+
| ID | NAME     | JOB     |
+----+----------+---------+
|  1 | userA    | Student |
|  2 | userB    | Student |
|  3 | modified | Student |
|  4 | Test     | Student |
+----+----------+---------+
4 rows in set (0.000 sec)

• 이처럼 세션 1 트랜잭션에서 특정 ROW의 데이터가 수정(삭제) + Commit 되어도 세션 2 트랜잭션에서는 데이터가 변경되기 전의 데이터로 조회가 된다.

 

• 즉, 트랜잭션 내에서 한 번 조회한 데이터를 반복해서 조회해도 같은 데이터가 조회된다는 것이다.

 

• 따라서, “Read Committed” 격리성 수준에서 발생하던 Non-Repeatable Read 문제는 해결이 되었다.

 

• 이는 세션 1 트랜잭션에서 데이터가 수정/삭제 + Commit 되더라도 세션 2 트랜잭션에서는 실제 데이터가 아닌 세션 1 트랜잭션에서 UNDO 로그에 저장한 백업 데이터를 가져오기 때문이다.

 

• 다만, 세션 1 트랜잭션에서 데이터를 추가(INSERT) 및 Commit 하게 되면 세션 2 트랜잭션에서 Phantom Read 문제가 발생해야 하지만 InnoDB 스토리지 엔진은 넥스트 키 락을 이용하여 Phantom Read 문제를 해결하기 때문에 Phantom Read 문제가 발생하지 않는다.

 

(2-4) Serializable Read - 직렬화가 가능 (여러 트랜잭션이 줄서서 기다리며 하나씩 처리됨)

트랜잭션 내에서 쿼리를 두 번 이상 수행할 때, 첫 번째 쿼리에 있던 레코드가 사라지거나 값이 바뀌지 않음은 물론 새로운 레코드가 나타나지도 않도록 한다.

• 가장 단순한 격리 수준이면서 가장 엄격한 격리 수준으로 격리성으로 인해 발생할 수 있는 3가지 문제를 모두 커버 가능하지만 다른 트랜잭션 격리성 수준보다 동시 처리 성능은 현저히 떨어진다.

 

• 한 트랜잭션에서 읽고 쓰는 레코드를 다른 트랜잭션에서는 격리성 정의 그대로 절대 접근할 수 없기 때문에 여러 트랜잭션이 줄서서 하나씩 처리된다.

 

• 다만 일반적인 DBMS에서는 Serializable Read 수준에서는 Phantom Read 문제가 발생하지 않지만 InnoDB 스토리지 엔진을 사용하는 DBMS에서는 Repeatable Read 격리 수준에서도 Phantom Read가 발생하지 않기 때문에 굳이 Serializable Read 격리 수준을 사용할 필요성은 없다.

 

• 참고로 데이터를 읽거나 쓸 때 내부적으로 Lock이 사용되며 DBMS 마다 사용되는 Lock 메커니즘은 다를 수 있다.

# 실습 
[세션 1, 2 공통]
set tx_isolation = 'SERIALIZABLE’;
SET AUTOCOMMIT = FALSE
START TRNASACTION;

[세션 2]
MariaDB [mysql]> select * from emp;
+----+-------+---------+
| ID | NAME  | JOB     |
+----+-------+---------+
|  1 | userA | Student |
|  2 | userB | Student |
|  3 | userC | Student |
+----+-------+---------+
3 rows in set (0.000 sec)

[세션 1]
INSERT INTO EMP VALUES (4, “Test”, “Student”);

→ 세션 2 트랜잭션에서 해당 테이블에 Lock을 걸어놓았기에 해당 INSERT문은 실행되지 않고 대기 상태로 빠지게 된다.

UPDATE EMP SET NAME = ‘modified’ WHERE ID = 3;

→ UPDATE문 또한 마찬가지로 해당 테이블에 Lock이 걸려있어 해당 UPDATE문은 실행되지 않고 대기 상태로 빠지게 된다.

[정리]

• 사용하는 DBMS에서 어떤 트랜잭션 격리 수준을 제공하고, 각 트랜잭션 격리 수준에서 발생할 수 있는 문제를 인지하는 것은 매우 중요하다!

 

• 위의 그림에서 Repeatable Read 격리 수준은 InnoDB 엔진을 사용할 경우, Phantom Read 문제는 발생하지 않는다.

 

[참고] 트랜잭션 격리성 수준과 DB Lock의 상관관계

• 트랜잭션 격리성 수준과 DB Lock은 데이터베이스의 트랜잭션 관리에서 중요한 개념으로, 데이터의 일관성과 동시성을 조절하는 데에 사용되어진다.

 

• 격리성 수준과 DB Lock은 비슷한 개념처럼 보일 수 있지만 서로 다른 개념이고 아래와 같은 차이점이 있다.

 

① 개념적 차이
트랜잭션 격리성 수준은 데이터베이스에서 여러 트랜잭션들이 동시에 실행될 때, 서로에게 어떻게 영향을 미치는 지를 결정하는 설정으로 격리성 수준은 트랜잭션들 간의 동시 접근과 데이터 일관성을 보장하는데 사용된다.

 

DB Lock은 데이터베이스에서 여러 트랜잭션들이 동시에 데이터에 접근할 때, 데이터의 일관성을 보장하기 위해 사용되는 메커니즘으로 Lock은 트랜잭션들이 데이터를 읽거나 쓰는 동안 다른 트랜잭션들이 해당 데이터에 대한 접근을 제한함으로써 동시성 문제를 방지한다.

 

② 적용 범위
트랜잭션 격리성 수준은 데이터베이스 전체에 적용되는 설정이며, 각 트랜잭션은 이 격리성 수준에 따라 동작한다.

격리성 수준은 트랜잭션의 시작 시점에 설정되며, 해당 트랜잭션의 수행 도중에 변경되지 않는다.

 

DB Lock은 개별 데이터나 데이터 블록에 적용되는 Lock 메커니즘으로 특정 트랜잭션이 데이터를 읽거나 쓰기 위해 해당 데이터에 대한 Lock을 획득하고 작업이 완료된 후에 Lock을 해제한다.

 

③ 자동관리 vs 수동관리
트랜잭션 격리성 수준은 데이터베이스 시스템이 자동으로 관리하는 설정이며 개발자가 직접 락을 설정하거나 해제할 필요가 없다.

 

DB 락은 개발자가 특정 데이터에 대해 Lock을 수동으로 설정하고 해제해야 한다.

 

④ 동시성과 일관성 보장
트랜잭션 격리성 수준은 트랜잭션들 간의 동시 접근과 데이터 일관성을 보장하는데 사용되며, 격리성 수준을 높일수록 데이터 일관성은 보장되지만 동시성은 감소할 수 있다.

 

DB Lock은 동시성을 관리하여 여러 트랜잭션이 데이터를 동시에 접근하는 것을 제어함으로써 데이터 일관성을 보장한다.

 

→ 요약하자면 트랜잭션 격리성 수준과 DB 락은 데이터베이스의 동시성과 데이터 일관성을 관리하는 데 사용되는 개념이다!

 

→ 트랜잭션 격리성 수준은 데이터베이스 전체에 적용되는 설정으로, 격리성 레벨에 따라 데이터베이스는 동시 접근을 조절하기 위해 DB Lock을 설정하고 해제한다.

 

→ DB Lock의 설정과 해제는 데이터베이스 시스템 내부에서 자동으로 처리하며 각각의 격리성 레벨에 따라 사용되는 DB Lock 메커니즘은 DBMS마다 다를 수 있다.

 

→ 즉, 격리성 레벨은 데이터베이스에서 사용되는 DB Lock의 종류와 동작 방식을 결정하며 각 격리성 레벨에 따라 데이터베이스는 읽기와 쓰기에 어떤 DB Lock을 사용할지 자동으로 설정하고 격리성 레벨이 높을수록 더 강력한 DB Lock이 사용되며 동시 접근이 제한되고 데이터 일관성이 보장되어진다.

 

→ 따라서, 적절한 격리성 레벨을 설정함으로써 데이터베이스 시스템이 알아서 DB Lock을 관리하게 되므로 개발자는 격리성 레벨만 적절히 선택하여 트랜잭션의 동시성과 일관성을 조절하며 Lock 관리에 신경쓰지 않고 데이터베이스 조작에 집중할 수 있다.

 

→ 다만, 말했다시피 격리성 수준은 데이터베이스 전체에 적용되는 설정이므로 데이터 일관성을 위해 높은 격리성 수준을 사용하게 되면 동시성이 감소할 수 있으므로 성능을 감안하여 적절한 격리성 레벨을 선택하고 필수적으로 데이터 일관성이 보장되어야 하는 테이블[데이터]에 한해 개발자가 수동으로 DB 락을 설정한다.

 

[Reference]

https://armful-log.tistory.com/57

[DB] 트랜잭션 특징, 격리 수준, 관련 문제점

https://luran.me/305

DB 트랜잭션 - 격리수준(Transaction Isolation Level)

https://sabarada.tistory.com/117

[데이터베이스] 트랜잭션과 격리성

https://incheol-jung.gitbook.io/docs/q-and-a/db/isolation-level

Isolation level - Incheol's TECH BLOG

https://jordy-torvalds.tistory.com/entry/%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98%EA%B3%BC-%EA%B2%A9%EB%A6%AC-%EB%A0%88%EB%B2%A8-%EA%B7%B8%EB%A6%AC%EA%B3%A0-Lock%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC

트랜잭션과 격리 레벨 그리고 Lock에 대하여

https://zzang9ha.tistory.com/381

[MySQL] - 트랜잭션의 격리 수준(Isolation level)

https://overcome-the-limits.tistory.com/528

[데이터베이스] 트랜잭션

- ChatGPT 포함