2025-08-24

오늘 배운 것

5.4 MySQL의 격리수준

  • 트랜잭션의 격리 수준 : 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 말지를 결정하는 것
    • READ UNCOMMITED(DIRTY READ)
      • 일반적인 데이터베이스에서 거의 사용하지 않음
    • READ COMMITED
    • REPEATABLE READ
    • SERIALIZABLE
      • 동시성이 중요한 데이터베이스에서는 거의 사용되지 않음
  • 뒤로 갈수록 각 트랜잭션 간의 데이터 격리 정도가 높아지고 동시 처리 성능도 떨어짐
  • 부정합의 문제

    • 격리 수준의 레벨에 따라 발생할 수도 있고 발생하지 않을 수도 있음

        DIRTY READ NON-REPEATABLE READ PHANTOM READ
      READ UNCOMMITED ✅ ✅ ✅
      READ COMMITED ❌ ✅ ✅
      REPEATABLE READ ❌ ❌ ✅
      SERIALIZABLE ❌ ❌ ❌
  • InnoDB에서는 독특한 특성 때문에 REPEATABLE READ 격리 수준에서도 PHANTOM READ가 발생하지 않음
  • 일반적인 온라인 서비스 용도의 데이터베이스는 READ COMMITTED와 REPEATABLE READ 중 하나를 사용

5.4.1 READ UNCOMMITED

  • 각 트랜잭션에서의 변경 내용이 COMMIT이나 ROLLBACK 여부에 상관 없이 다른 트랜잭션에서 보임
    • 따라서 문제가 발생하여 롤백되어도 정상적인 데이터라고 인식하는 문제가 발생할 수 있음
  • DIRTY READ : 어떤 트랜잭션에서 처리한 작업이 완료되지 않았는데도 다른 트랜잭션에서 볼 수 있는 현상

5.4.2 READ COMMITED

  • COMMIT이 완료된 데이터만 다른 트랜잭션에서 조회가능
  • NON-REPEATABLE READ : 한 트랜잭션 내에서 똑같은 SELECT 쿼리를 여러번 실행했을 때 다른 결과가 발생하는 것
    • 금전적인 처리와 연결되면 문제가 발생할 수 있음
  • READ COMMITED는 트랜잭션 내에서 실행되는 SELECT와 트랜잭션 없이 실행되는 SELECT 문장의 차이가 별로 없음
    • REPETABLE READ는 기본적으로 SELECT 문장도 트랜잭션 범위 내에서만 작동

5.4.3 REPEATBLE READ

  • MySQL의 InnoDB 스토리지 엔진에서 기본으로 사용되는 격리 수준
  • 바이너리 로그를 가진 MySQL 서버에서는 최소 REPEATABLE READ 격리 수준 이상을 사용해야함
  • NON-REPETABLE READ 부정합이 발생하지 않음
  • READ COMMITED 와 REPEATBLE READ의 차이
    • 언두 영역의 백업된 레코드의 여러 버전 가운데 몇 번째 이전 버전가지 찾아 들어가야 하는가!
    • REPEATBLE READ는 MVCC를 보장하기 위해 실행 중인 트랜잭션 가운데 가장 오래된 트랜잭션 번호보다 앞선 언두 영역의 데이터는 삭제할 수 없음
      • 더 정확하게는 특정 트랜잭션 번호의 구간 내에서 백언된 언두데이터가 보존되어야 함
        • 따라서 언두에 백업된 레코드가 많아지면 서버의 처리 성능이 떨어질 수 있음 → 트랜잭션의 범위및 길이를 잘 고려해야함
    • 그래서 자신의 트랜잭션 번호보다 작은 트랜잭션 번호에서 변경한 것만 보게 됨
  • PHANTOM READ : 다른 트랜잭션에서 수행한 변경작업에 의해 레코드가 보였다가 안보였다 하는 현상

5.4.4 SERIALIZABLE

  • 가장 단순한 격리 수준이면서 동시에 가장 엄격한 격리 수준
  • 동시 처리 성능도 다른 트랜잭션 격리 수준보다 떨어짐
  • 읽기 작업도 공유잠금을 획득해야만 하고, 동시에 다른 트랜잭션은 그러한 레코드를 변경하지 못하게 됨
  • 따라서 PHANTOM READ라는 문제가 발생하지 않음
    • 그런데 InnoDB 스토리지 엔진에서는 갭락과 넥스트키락 덕분에 REPEATABLE READ 격리 수준에서도 이미 PHANTOM READ가 예외 상황을 제외하곤 거의 발생하지 않기 때문에 굳이 SERIALIZABLE을 사용할 필요성은 없음

results matching ""

    No results matching ""