InnoDB에서 사용되는 Lock의 종류

레코드 락

• 의미 그대로 레코드 자체에 대해서 잠그는 락

Gap 락

• 레코드와 레코드 사이의 간격을 잠그는 락
• 레코드 자체에 대해서는 잠그지 않음
• 매뉴얼상에서는 특정 레코드 키 이전의 간격을 잠그는 것으로 표현되어 있지만, 레코드 키 이전과 이후의 간격을 모두 포함하는 것 같기도 함
  -> 예를 들어서 레코드가 [1],[2],[3]이 있을 경우, 레코드 키 [2]에 변경 작업이 발생하는 경우 Gap 락이라 함은
      1<Gap<2 와 2<Gap<3의 두개의 범위를 모두 포함하는 것으로 보임
• Gap 락의 가장 큰 목적은 아래 두 가지로 보임
  -> Master 와 Slave의 데이터 동기화 (더 정확히는 Binary 로그의 정확한 기록을 위해서)
  -> Phantom 레코드 방지 
• InnoDB의 Gap 락은 생각보다 많은 Concurrency 저하를 가져온다고 생각됨
  -> 물론 Dead lock도 유발될 가능성이 높음
• InnoDB에서 대 부분의 변경 작업들은 Gap 락을 유발함
• Primary Key 업데이트는 레코드 락만 유발하며 Gap 락을 걸진 않음
• Gap 락을 가지고 있다고 해서 그 간격에 Insert가 허용되는 것은 아님 (단순 예방용 락 일뿐임)
• 만약 그 간격에 Insert를 하고자 하면, 반드시 충돌되는 락들이 모두 해제되기를 기다려야 함
• Gap 락은 자동으로 확장 및 다른 트랜잭션의 Gap 락과 통합되기도 함
  -> Gap 락은 순수하게 모든 트랜잭션을 대상으로 해당 Gap에 변경 작업을 하지 못하도록 하는 예방용으로만 사용되기 때문임
  -> 예를 들어 레코드 키 [1], [2], [3]이 있는데, 트랜잭션 1번이 1<Gap<2 를 가지고 있고, 트랜잭션 2번이 2<Gap<3을 가지고 있는데,
      어떤 이유에서 레코드 키 [2]가 삭제된다면, 이 두개의 Gap 락은 1개의 Gap 락( 1< Gap <3)으로 통합되어
      트랜잭션 1번과 트랜잭션 2번이 이 통합된 Gap 락을 공유하게 됨
      (실제로 Purge thread가 레코드 키 [2]를 삭제하는 경우 이런 현상이 발생함) => 별로 중요치 않음

Next-key 락

• 레코드 락과 Gap 락을 합친 락
  -> 예를 들어서 레코드가 [1],[2],[3]이 있다면, 레코드 [2]에 대해서 변경이 진행된다면 1< Gap + record <3 의 범위에 대해서 락이 걸림

Auto-increment 락

• Auto Increment 속성의 컬럼을 가진 테이블에 Insert가 실행되는 경우 걸리는 락 (다른 여타의 락과는 조금 다름)
  -> Auto increment 컬럼에 값이 제공되어도 여전히 Auto increment 락은 걸림
• InnoDB의 다른 락과는 달리 Auto-increment 락은 테이블 레벨의 락임
• 다른 락들은 트랜잭션 단위의 락이지만, Auto-increment 락은 Statement 레벨의 락임
  -> 트랜잭션과 관계없이 Statement(Query문장)가 종료되면 락이 해제됨
  -> 이 특성으로 유추할 수 있는 것은 InnoDB의 Auto increment는 값이 한번 사용되어지면
      트랜잭션이 Rollback되어도, 이미 사용된 Auto increment 값은 복구되지 않는 다는 것을 예측할 수 있음
• MySQL 5.0 까지는 위와 같이 작동하며, Concurrent insert가 매우 빈번한 경우에는 Auto increment 락이 병목이 될 가능성이 있음
• MySQL 5.1에서는 아래와 같이 설정함으로써, 병목 회피 가능
  -> innodb_autoinc_lock_mode = 1 : 단순한 Insert에 대해서는 락을 걸지 않음
  -> innodb_autoinc_lock_mode = 2 : 어떠한 경우에도 락을 걸지 않음 (Row level의 replication 을 사용할 경우에만 사용 가능함)

Insert intention lock

• Gap (레코드 키 사이에)에 데이터를 Insert하기 위해서 기다릴 때 거는 락