5-4. 격리 수준

격리 수준

•

SERIALIZABLE 말고는 크게 성능의 개선이나 저하 발생 X

부정합 테이블

	DRITY READ	NON-REPEATABLE READ	PHANTOM READ
READ UNCOMMITTED	발생	발생	발생
READ COMMITTED	없음	발생	발생
REPEATABLE READ	없음	없음	발생(InnoDB는 없음)
SERIALIZABLE	없음	없음	없음

READ UNCOMMITTED

•

dirty read: commit, rollback 여부에 상관없이 다른 트랜잭션에서 변경 내용이 보이는 현상

# session 1
start transaction;
update morak.member set name='eden2' where id=1;
insert into member;

# session 2
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
select * from morak.member;
# commit 안했는데 변경된 내용이 보인다.
SQL
복사

READ COMMITTED

•

언두로그 데이터 반환

•

non-repeatable read: 하나의 트랜잭션 내에서 똑같은 조회 쿼리를 실행했을 때 항상 같은 결과를 가져와야 한다는 repeatable read 정합성에 어긋나는 현상

# session 2
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
start transaction;
select * from member where name='eden2';
# 결과 없음

# session 1
start transaction;
update morak.member set name='eden2' where id=1;
commit;
# session 2s
elect * from member where name='eden2';
# 결과 조회됨
SQL
복사

•

예시: 하나의 트랜잭션에서 입금과 출금 처리가 계속 진행될 때 다른 트랜잭션에서 오늘 입금된 금액의 총합을 조회할 때 문제

REPEATABLE READ

•

InnoDB 스토리지 엔진 기본 격리 수준

•

바이너리 로그를 가진 MySQL 서버에서는 최소 REPEATABLE READ 격리 수준 이상 사용

•

변경하기 전 레코드를 언두 공간에 백업해두고 레코드 값 변경 -> MVCC 라고 함

•

언두 영역에 백업된 이전 데이터를 활용하여 동일 트랜잭션 내에서 동일 결과 보여줄 수 있게 보장

언두 영역

•

사실 READ COMMITTED 도 언두 로그 조회

•

REPEATABLE READ 와 READ COMMITTED 의 차이는 언두 영역에 백업된 레코드의 여러 버전 중 몇 번째 이전 버전까지 찾아 들어가는지

•

언두 영역에 백업된 모든 레코드에는 변경을 발생시킨 트랜잭션 번호 포함

•

언두 영역에 백업된 데이터는 InnoDB 스토리지 엔진이 불필요하다고 판단하는 시점에 주기적으로 삭제

•

REPEATABLE READ 격리 수준에서는 MVCC 를 보장하기 위해 실행 중인 트랜잭션 중 가장 오래된 트랜잭션 번호보다 트랜잭션 번호가 앞선 언두 영역의 데이터 삭제 불가

•

begin 으로 트랜잭션을 시작하고 장시간 트랜잭션을 종료하지 않으면 언두 영역에 데이터가 무제한 쌓일 수 있다.

•

언두 영역 레코드에는 잠금을 걸 수 없다

# session 2
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
start transaction;
select * from member;
# 6개의 row
# start transaction 뒤 어떠한 쿼리도 없으면 transaction 이 등록되지 않는다. 그래서 팬텀 리드 테스트 불가능

# session 1
start transaction;
insert into member;
commit;

# session 2
select * from member;
# 6개의 row

select * from member for update;
# 7개의 row
# 언두 영역에는 잠금을 못 걸어서 실제 테이블에서 가져 와야해서 그런듯?

select * from member;
# 6개의 row

delete from member where id=7;
# Query OK, 1 row affected (0.01 sec)
SQL
복사

session 1 에 select * from member where name='eden' for update 를 걸었다.

SERIALIZABLE

•

가장 엄격한 격리 수준

•

동시 처리 성능 최하

•

읽기 작업도 공유 잠금을 획득해야 한다

•

non-locking consistent read

•

InnoDB 멀티 버저닝

SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
start transaction;

select * from morak.member where id=1;
# member 의 id=1 인 레코드에 S,REC_NOT_GAP 락 걸림

select * from morak.member;
# 모든 member 레코드에 S 락 걸림

update member where id=1;
# member 의 id=1 인 레코드에 X,REC_NOT_GAP 락 걸림

delete from member where name='zz';
# 모든 member 레코드에 X 락 걸림
SQL
복사