Daily Dev Q&A: 트랜잭션과 인덱스의 관계

2026. 1. 29. 12:10·Archive/Daily Dev Q&A

Topic (오늘의 주제)

트랜잭션과 인덱스의 관계 (Relationship between Transaction and Index)

Why (왜 사용하는가? 왜 중요한가?)

  • 실무: 트랜잭션 내에서 데이터를 수정(UPDATE, DELETE)할 때, 인덱스가 없으면 불필요한 데이터까지 잠금(Lock)이 걸려 서비스 전체가 멈추는 심각한 동시성 문제가 발생할 수 있습니다.
  • 구조적 의미: 인덱스는 트랜잭션의 대상 검색 속도는 높여주지만, 실제 변경 작업 시 인덱스 정렬 비용을 발생시켜 쓰기 성능을 저하시키는 양날의 검(Trade-off) 관계입니다.
  • 면접 의도: 단순히 인덱스가 "빠르다"는 것을 넘어, 인덱스가 DB의 잠금(Locking) 메커니즘과 트랜잭션 성능에 미치는 영향을 깊이 있게 이해하고 있는지 확인합니다.

Core Concept (핵심 개념 정리)

관계 요소 내용 설명
쓰기 성능 (Performance) 반비례 관계 트랜잭션이 INSERT, UPDATE, DELETE를 수행하면, 실제 데이터뿐만 아니라 모든 인덱스도 함께 수정 및 재정렬해야 하므로 트랜잭션 처리 시간이 길어집니다.
수정 대상 검색 (Lookup) 비례 관계 UPDATE user SET ... WHERE id = 10 같은 쿼리 실행 시, id에 인덱스가 있으면 대상을 빨리 찾아서 트랜잭션 시작 시간을 단축시킵니다.
잠금 (Locking) 범위 제어 (중요) 데이터베이스(특히 MySQL InnoDB)는 인덱스를 기준으로 락(Lock)을 겁니다. 인덱스가 없으면 테이블 전체를 잠그는 불상사가 발생할 수 있습니다.

상세 메커니즘: 인덱스와 락(Lock)

  • 인덱스 있음: WHERE 조건에 맞는 특정 레코드(Row)만 잠금 → 동시성 높음.
  • 인덱스 없음: 조건에 맞는 레코드를 찾기 위해 테이블 전체를 스캔하면서 마주치는 모든 레코드를 잠금 → 동시성 최악 (다른 트랜잭션 대기 발생).

Interview Answer Version (면접 답변식 요약)

"트랜잭션과 인덱스는 성능과 동시성 측면에서 밀접한 관계가 있습니다.

우선 성능 면에서, 인덱스는 트랜잭션 내의 수정 대상을 빠르게 찾는 데는 도움을 주지만, 실제 데이터 변경 시 인덱스도 함께 갱신해야 하므로 쓰기 작업의 오버헤드를 증가시킵니다.

더 중요한 것은 동시성입니다. 데이터베이스는 주로 인덱스 레코드를 기준으로 락(Lock)을 걸기 때문에, 적절한 인덱스가 없다면 불필요한 레코드까지 잠그게 되어 데드락(Deadlock)이나 성능 저하를 유발할 수 있습니다."

Practical Tip (사용시 주의할 점 or 활용 예)

1. UPDATE/DELETE 시 인덱스 필수

  • UPDATE orders SET status = 'DONE' WHERE user_id = 'A';
  • 위 쿼리를 실행할 때 user_id에 인덱스가 없다면, DB는 user_id가 'A'인 것을 찾기 위해 전체 행을 훑으면서 모든 행에 락을 걸 수 있습니다. 이때 다른 사용자는 주문 생성(INSERT)조차 못 하게 됩니다. 수정/삭제 조건 컬럼에는 반드시 인덱스를 고려해야 합니다.

2. 대량 데이터 Insert 시 인덱스 해제

  • 수백만 건의 데이터를 한 번에 넣는 배치 작업(Batch) 트랜잭션의 경우, 인덱스가 켜져 있으면 한 줄 넣을 때마다 인덱스 트리를 재정렬하느라 시간이 매우 오래 걸립니다.
  • Tip: 인덱스를 잠시 삭제(Drop)하거나 비활성화한 후 데이터를 넣고, 다시 인덱스를 생성하는 것이 훨씬 빠를 수 있습니다.

3. 불필요한 인덱스 제거

  • 읽기 성능을 높이겠다고 인덱스를 너무 많이 만들면, 트랜잭션(쓰기) 성능이 급격히 떨어집니다. 사용하지 않는 인덱스는 주기적으로 모니터링하여 삭제해야 합니다.

예상 꼬리질문 정리

Q1. 인덱스가 걸려있지 않은 컬럼으로 업데이트를 하면 레코드 락(Row Lock)이 아니라 테이블 락(Table Lock)이 걸리나요?

  • 핵심 키워드: (MySQL InnoDB 기준) 엄밀히 말하면 테이블 락은 아니지만, 풀 테이블 스캔을 하면서 모든 레코드에 락을 걸기 때문에 사실상 테이블 락과 동일한 효과가 나타나 동시성이 크게 떨어집니다.

Q2. 트랜잭션 격리 수준(Isolation Level)과 인덱스는 무슨 관계가 있나요? (Phantom Read)

  • 핵심 키워드: Serializable 같은 높은 격리 수준에서는 유령 데이터(Phantom Read)를 막기 위해 인덱스의 사이 공간까지 잠그는 **넥스트 키 락(Next-Key Lock)**이나 **갭 락(Gap Lock)**이 발생합니다. 인덱스 구조에 따라 락의 범위가 결정됩니다.

Q3. 쓰기 지연(Write Ahead Log)이나 체인지 버퍼(Change Buffer)가 인덱스 성능 저하를 어떻게 보완하나요?

  • 핵심 키워드: 인덱스 변경 내용을 디스크에 바로 쓰지 않고 메모리(Change Buffer)에 임시로 모아두었다가, 나중에 한 번에 디스크에 병합(Merge)함으로써 랜덤 I/O 부하를 줄여 성능을 보완합니다.

'Archive > Daily Dev Q&A' 카테고리의 다른 글

Daily Dev Q&A: 데이터베이스 락  (0) 2026.02.02
Daily Dev Q&A: 데이터베이스 동시성 이슈  (0) 2026.01.29
Daily Dev Q&A: 관계형 데이터베이스의 인덱스  (1) 2026.01.27
Daily Dev Q&A: Cookie vs Session  (0) 2026.01.23
Daily Dev Q&A: HTTP vs HTTPS  (0) 2026.01.22
'Archive/Daily Dev Q&A' 카테고리의 다른 글
  • Daily Dev Q&A: 데이터베이스 락
  • Daily Dev Q&A: 데이터베이스 동시성 이슈
  • Daily Dev Q&A: 관계형 데이터베이스의 인덱스
  • Daily Dev Q&A: Cookie vs Session
tlsgkstj
tlsgkstj
짱구의 성장 일기
  • tlsgkstj
    코딩하는 짱구
    tlsgkstj
  • 전체
    오늘
    어제
    • 분류 전체보기 (159)
      • About (1)
      • Projects (35)
        • Personal Projects (21)
        • Team Projects (14)
      • Engineering (20)
        • CS & Tools (0)
        • Backend Core (15)
        • Frontend (1)
        • Infra & Cloud (2)
        • AI & Tools (1)
      • Trouble Shooting & Issues (0)
      • Growth & Career (38)
        • Interview Prep (0)
        • Retrospectives (38)
      • Archive (65)
        • TIL (8)
        • Daily Dev Q&A (56)
  • 블로그 메뉴

    • 홈
    • About
    • Projects
    • Tech Stack
    • Dev Log
    • GitHub
  • 링크

    • github
  • 공지사항

  • 인기 글

  • 태그

    SpringBoot
    java
    spring
    프로덕트개발자
    devlog
    클로드코드
    network
    프로젝트회고
    backend
    Project_Review
    jpa
    OrphanRemova
    til
    DevFestIncheon2025
    커리어리셋
    경기기후바이브코딩
    데브페스트
    REACT
    aws_s3
    Spring비교
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.5
tlsgkstj
Daily Dev Q&A: 트랜잭션과 인덱스의 관계
상단으로

티스토리툴바