- 05 트랜잭션과 잠금
- MySQL의 격리 수준
- Transaction isolation level이란 A 트랜잭션이 변경하고 있을 때, B라는 트랜잭션이 그 값을 볼 수 있게 할지 못하게 할지를 결정하는 수준.
- → 커밋되고 난 다음의 데이터를 봐! 아니야 커밋 되기전의 데이터를 봐! 그것도 아니야! 커밋과 상관 없이 너가 처음 보기 시작 했던 것 계속해서 쭉 봐!, 아 그것도 싫어 그냥 내 작업 끝날 때까지 넌 발도 들이지 마!
- 동시성의 결정하는 결정적인 설정. 결국 조회 성능과 직결 된다.
- ACID
- A - atomicity 원자성 . 트랜잭션은 성공하거나 실패하거나 둘중 하나여야 한다.
- C - consistency 일관성. 데이터 베이스에 걸어둔 제약은 지켜져야 한다. 트랜잭션이 이 제약을 망가트리면 안된다. 모든 유저는 아이디를 가진다 → 트랜잭션이 어떠한 유저의 아이디를 삭제한다. ⇒ 일관성 깨짐
- I - Isolation 격리성. 각각의 트랜잭션은 순서가 바껴서 실행이 되든 함께 실행이 되든 결과는 항상 일정하다.
- D - Durability 지속성. 한 번 저장된 데이터는 지속적으로 유지돼야 한다.
- READ UNCOMMITTED
-
아직 A가 커밋해서 완료하지도 않은 데이터(Dirty data)를 B에게 보여줌.
→ 만약 Tx A가 롤백이 되는 상황이 발생하면 문제가 심각해짐. DB에는 없는 데이터를 B라는 트랜잭션을 가지고 있는 상황.
-
- READ COMMITTED
- 커밋되어진 데이터만을 읽는다. 만약 A Tx이 변경하고 있을 때, B Tx도 그 데이터를 조회한다고 하면, A Tx이 버퍼 풀에서만 변경을 하고, 아직 커밋이 되지 않았다면, B에겐 A가 변경하기 전의 데이터가 커밋된 데이터이므로, 그 데이터를 읽는다. 그 데이터는 데이터 백업 공간인 언두 로그영역에서 참고해서 읽는다.
- 하지만 B가 처음에 LaLa를 조회 했고 같은 Tx안에서 다른 작업을 하다가 한참 후에 다시 LaLa일것이 자명한 데이터를 다시 조회 했더니, 듣도보도 못한 Toto로 바뀌어져 있는 상황 → NON-REPEATABLE READ
- REPEATABLE READ
- InnoDB에서 기본적으로 사용하는 격리 수준이다.
- READ COMMITTED와 비슷하게 언두 로그에서 커밋전의 데이터를 조회하지만, Tx-ID 값을 기준으로 자신의 Tx-ID보다 작은 Tx-ID의 데이터 값을 우선 조회한다. 다시 말해 자신의 Tx보다 나중에 데이터 변경 커밋을 실시한 Tx의 ID 값을 비교 할 수 있으므로, 그 Tx전의 바뀌기전 데이터를 언두 로그에서 찾아서 사용 할 수 있다.
- PHANTOM READ : 같은 Tx에서의 조회인데 1분전에는 없더 데이터가 갑자기 조회 됐다!!
- SERIALIZABLE
- 조회 작업도 락을 걸고 실시하게 된다. 그러므로 다른 트랜잭션이 끼어들지 못하여 동시성을 최악으로 떨어진다.
- MySQL의 격리 수준
좋은 영향력과 교류를 위하여