[Real MySQL 8.0] 트랜잭션과 MySQL / InnoDB의 락 (Lock)

🌱 들어가기 전

이번 포스팅에서는 트랜잭션에 대한 간단한 개념과, MySQL과 InnoDB 스토리지엔진에서 제공하는 락에 대해서 알아보자.
 

---

 

🌱 트랜잭션

트랜잭션은 하나의 논리적인 작업 셋에 완전히 적용(commit)되거나, 아무것도 적용되지 않음 (rollback)을 보장해야 한다.
InnoDB와 MyISAM 테이블은 트랜잭션 관점에서도 차이를 보이는데, 이를 확인해보자.
우선, 아래와 같이 myISAM과 innoDB를 사용한 2개의 테이블을 만들자.

CREATE TABLE tb_myisam (
    id INT NOT NULL,
    PRIMARY KEY (id)
) ENGINE=MYISAM;

CREATE TABLE tb_innodb (
    id INT NOT NULL,
    PRIMARY KEY (id)
) ENGINE=innodb;

 
그리고, 각각에 대해서 레코드를 1개씩 저장해보자.

insert into tb_myisam (id) values (3);
insert into tb_innodb (id) values (3);

 
이후, auto commit 모드를 활성화한 다음 다음과 같이 레코드를 추가해보자.

💡 AUTO COMMIT이란?
사용자가 commit 명령어를 사용하지 않아도 SQL문이 성공적으로 실행되면 자동으로 커밋을, 문제가 발생하면 알아서 롤백을 해준다. 기본적으로는 활성화가 되어 있다.

 

set autocommit = on;

insert into tb_myisam (id) values (1), (2), (3);
insert into tb_innodb (id) values (1), (2), (3);

당연히 primary key로 설정된 컬럼에 동일한 값을 넣으려고 했기 때문에, 두 테이블 모두 오류가 발생한다.
 
하지만, 실제로 select 했을 때의 결과는 다음과 같다.

tb_myisam

tb_innodb

 
myISAM으로 생성한 테이블의 경우 1, 2, 3 모두가 그대로 삽입되어 있는 것이다.
이는, 롤백이 발생하지 않았다기보다는, 쿼리문에서 1, 2는 삽입 성공했지만 3을 삽입한 순간에 오류가 발생하여 3에 대해서만 삽입하지 않고 종료한 것이다. 반면에, innoDB의 경우 우리가 흔히 생각한 것처럼 1, 2, 3 모두를 삽입하는 쿼리에 대해서 롤백을 한다.
이런 현상을 'Partial Update'라고 하며, 데이터의 경합성을 맞추는 데 어려움을 주는 요소 중 하나이다.
왜 innoDB를 많이들 사용하는지 한 가지 이유를 더 알아간다 😎
 

---

 

🌱 락 - MySQL

MySQL에서 락은 크게 스토리지 엔진 레벨과 MySQL 엔진 레벨로 나눌 수 있다.
MySQL 엔진 레벨의 락은 글로벌 락, 테이블 락, 메타데이터 락, 네임드 락을 제공한다.
 
 

💬 글로벌 락

MySQL에서 제공하는 락 중에서 가장 범위가 큰 락이다.

FLUSH TABLES WITH READ LOCK

하나의 세션에서 글로벌 락을 획득하면 다른 세션에서 select를 제외한 대부분의 DDL / DML 문장 실행 시, 글로벌 락이 해제될 때까지 계속 대기 상태로 남게 된다. MySQL 서버 전체에 영향을 주기 때문에 작업 중인 테이블이나 데이터베이스를 넘어서 동일하게 영향을 준다.
 
만약, 글로벌 락이 실행되기 전에 쓰기 락이 걸린 SQL이 실행됐다면, 기존의 쓰기 락이 완전히 해제된 이후에 글로벌 락이 걸리게 된다. 즉, 현재 실행 중인 모든 쿼리가 완료되어야만 글로벌 락을 실행할 수 있는 것이다. 하지만, MySQL 8.0부터 Xtrabackup, Enterprise Backup 같이 '백업 락'이라는 조금 더 가벼운 락이 추가되었다.

# 백업 락
LOCK INSTANCE FOR BACKUP;

# 락 해제
UNLOCK INSTANCE;

 
백업 락의 경우 특정 세션에서 획득하면 모든 세션에서 아래와 같은 정보를 변경할 수 없다.

- 데이터베이스나 테이블 등, 모든 객체의 생성 및 변경, 삭제
- REPAIR TABLE / OPTIMIZE TABLE
- 사용자 관리 및 비밀번호 변경

하지만, 일반적인 테이블의 데이터 변경은 허용하기 때문에 이전의 글로벌 락보다 확실히 완화된 락을 사용할 수 있다.
기존의 글로벌 락을 사용했다면 복제용 서버 (레플리카 서버)에서 데이터의 복제가 일어나는 도중에 기존 서버에서 오류가 생겼다면 백업 역시 계속 지연 / 혹은 실패했을 것이다. 백업이라는 것은 상당히 오래 걸리는 작업이기 때문에 실패 시에 또 다시 엄청난 시간을 들여야 하고, 그러면 서비스 자체에도 영향이 크기 때문에 이러한 문제를 해결하기 위해서 '백업 락'이라는 것이 도입되었다.
 

---

 

💬 테이블 락

테이블 락의 경우 테이블 단위로 설정하는 잠금이며, 명시적 (explicit) / 암시적 (implicit) 락을 획득할 수 있다.

# 락 획득
LOCK TABLES table_name [READ | WRITE]

# 락 해제
UNLOCK TABLES

 
락을 획득할 때 2개의 옵션을 줄 수 있는데, 하나는 READ, 하나는 WRITE이다.

READ
- 테이블에 대한 읽기 락 획득
- 다른 세션이 동시에 같은 테이블에 대한 읽기 락 획득 가능
- 테이블에 대한 내용은 읽을 수 있지만, 수정은 불가능 
- 동시에 다른 세션이 해당 테이블에 대해서 쓰기 락 획득 불가능

WRITE
- 테이블에 대한 쓰기 락 획득 
- 다른 세션이 동시에 같은 테이블에 대한 읽기 락, 쓰기 락 획득 불가능
- 쓰기 락을 획득한 세션은 테이블의 내용을 읽고 수정할 수 있음

 
명시적 락의 경우 위와 같이 쿼리를 통해서 직접적으로 선언하는 방법이며, 묵시적 락의 경우 테이블을 변경하는 쿼리를 실행했을 때 MySQL 서버가 해당 테이블에 락을 설정하고 데이터를 변경한 다음, 바로 락을 해제하는 형태로 사용된다. 자동으로 할당 및 해제가 일어나기 때문에 편리하지만, innoDB의 경우 레코드 기반 락을 제공하기 때문에 테이블 락이 실행되더라도 DML에서는 무시되고, DDL에서만 영향을 준다.
 

---

 

💬 네임드 락

테이블, 레코드가 아닌 임의의 문자열에 대해 잠금을 획득할 수 있다. (일종의 변수 느낌?)
1대의 DB 서버에 여러 대의 웹 서버가 접속하였을 때 특정 정보를 동기화해야 하는 상황에서 네임드락을 사용할 수 있다.

# hello라는 문자열에 대해서 잠금 획득
# 이미 사용 중이라면 2초 대기 후 해제
SELECT GET LOCK('hello', 2);

# 잠금이 설정되어 있는지 확인
SELECT IS_FREE_LOCK('hello');

# hello라는 문자열에 대해 획득했던 잠금 해제
SELECT RELEASE_LOCK('hello');

3가지 쿼리 모두 select문의 결과로 락을 정상적으로 획득하거나 해제하면 1을, 아니라면 null이나 0을 반환한다.
 

# 동시에 락 걸기
SELECT GET_LOCK('hello1', 10);
SELECT GET_LOCK('hello2', 10);

# 모두 해제
SELECT RELEASE_ALL_LOCKS();

네임드 락의 경우 복잡한 조건으로 레코드를 한꺼번에 많이 변경할 때 사용하며, MySQL 8.0부터는 네임드 락을 중첩하여 사용하는 것을 가능하도록 만들었다.
 

---

 
💬 메타데이터 락

테이블이나 뷰의 이름이나 구조를 변경하는 경우, 메타데이터 락을 획득한다. 
명시적으로 획득하거나 해제가 안 되며 RENAME 등의 쿼리를 실행할 때 자동으로 획득하는 잠금이다.

# 이러면 tb_1, tb_2 모두에 대해서 잠금을 설정한다
RENAME TABLE tb_1 TO tb_2;

 
테이블의 이름을 변경할 때 혹시나 실서비스에서 '해당하는 테이블이 없습니다' 같은 경고 메시지가 뜨지 않도록 하기 위해서는, 하나의 rename table 쿼리에 여러 개의 조건을 넣어두면 된다.

RENAME TABLE tb_1 to tb_2, tb_3 to tb_1

이렇게 되면 tb_1에 대해서는 tb_2로 바꾸면서, 기존의 tb_3을 tb_1이라는 이름으로 바로 바꾸기 때문에 경고 메시지가 뜨지 않는다.
 
 

💡 테이블 락 + 메타데이터 락 

로그 정보를 저장하는 로그 테이블이 있다고 생각해보자. 단순히 사용자의 웹 요청에 대한 정보를 저장하기 때문에 INSERT만 진행되는 테이블이다. 하지만, 테이블의 구조를 변경해야 한다면 어떻게 해야 할까?
기본적으로 MySQL의 DDL을 사용한다면 단일 스레드로 동작하기 때문에 시간이 오래 걸릴 것이다. 
보통 이런 경우에는 새로운 테이블을 생성하고, 비교적 최근 데이터를 제외하고 PK로 범위를 나눈 레코드들에 대해 여러 개의 스레드로 복사하는 게 일반적이다.

INSERT INTO tb_new SELECT * FROM tb_origin WHERE id >= 0 AND id <= 10000;

 
그리고, 남은 데이터에 대해서는 양이 적기 때문에 테이블 구조 변경이 용이해지며, 비교적 서비스에 덜 영향을 미치게 된다.

# auto commit 모드 끄기
SET autocommit = 0;

# 대상 테이블에 대해서 쓰기 락 획득 (테이블 락)
LOCK TABLES tb_origin WRITE, tb_new WRITE;

# 남아있는 데이터를 복사해주기
SELECT MAX(id) AS @max_id FROM tb_new;
INSERT INTO tb_new SELECT * FROM tb_origin WHERE id > @max_id;
COMMIT;

# 복사 완료 시 rename 진행 (메타데이터 락)
RENAME TABLE tb_origin TO tb_origin_old, tb_new to tb_origin;

# 임시 테이블 삭제
DROP TABLE tb_origin_old

이렇게 되면 테이블 락의 경우 20000~20100번째 레코드를 복사할 때만 걸리기 때문에, 기존 데이터를 tb_new로 복사할 때 최대한 많은 데이터를 복사해둬야 락을 점유하는 시간이 짧아진다.
 

---

 

🌱 락 - innoDB 스토리지 엔진

innoDB에서는 MySQL에서 제공하는 락과는 별도로 락을 제공하고 있다.
기본적으로 information_schema 테이블의 INNODB_TRX, INNODB_LOCKS, INNODB_LOCK_WAITS 테이블에 있는 정보들을 바탕으로 어떤 트랜잭션이 락을 점유하고 대기 중인지 알 수 있으며, 여러 모니터링 방법들을 통해서 스토리지 엔진에서 제공하는 락까지 효율적으로 관리할 수 있도록 돕고 있다.
 
innoDB에서는 총 8가지의 락을 제공하고 있으며, 이는 다음과 같다.

- Shared / Exclusive Lock
- Intention Lock
- Record Lock
- Gap Lock
- Next-Key Lock
- Insert Intention Lock
- Auto-increment Lock
- Predicate Lock for Spatial Indexes

 

---

 
 

💬 Shared / Exclusive Lock (공유 락, 베타 락)

공유 락(S-Lock)과 배타 락(X-Lock)이라는 레코드 레벨의 락이며, 공유 락의 경우 해당 락을 보유한 트랜잭션이 해당 레코드를 읽을 수 있도록 하고, 배타 락의 경우 해당 잠금을 보유한 트랜잭션이 행을 업데이트하거나 삭제할 수 있도록 만드는 것이다.
 
앞서 말했던 테이블 락의 READ / WRITE 모드와 거의 비슷하다고 생각하면 된다.
트랜잭션 A가 S-Lock을 가지고 있을 때 트랜잭션 B는 S-Lock을 보유할 수 있지만, 트랜잭션 A가 X-Lock을 가지고 있다면 어떤 락 요청이든 허용되지 않고 계속 대기해야 한다.
 

---

 

💬 Intention Lock (의도 락)

의도 락(Intention Lock)의 경우 테이블 락과 레코드 락이 공존할 수 있도록 만든다.
테이블의 특정 레코드에 대해서 추후 락을 걸겠다고 표현하는 것과 같다.
만약 WRITE 모드의 테이블 락을 걸었다면, innoDB에서는 2가지의 타입으로 의도 락을 수행한다.

Intention Shared Lock (IS)
- 트랜잭션이 테이블의 개별 레코드에 공유 락 설정

Intention Exclusive Lock (IX)
- 트랜잭션이 테이블의 개별 레코드에 베타 락 설정

 
만약 SELECT ... LOCK IN SHARE MODE을 실행한다면 해당 테이블에 대해서 먼저 IS 이상의 락을 걸고, 그 다음 레코드에 대해서 S-Lock이 걸리며, SELECT ... FOR UPDATE의 경우 해당 테이블에 대해서 먼저 IX 이상의 락을 걸고, 그 다음에 레코드에 X-Lock이 걸린다. 왜 이렇게 2번 거는 것일까?
- 이는, 트랜잭션 A에서 이미 테이블에 대해 락을 걸어두었기 때문에 다른 트랜잭션에서 해당 테이블의 레코드에 접근하여 락을 걸지 못하도록 하기 위해서이다. 쓰기 작업 시 이미 IX 락이 걸려 있기 때문에 다른 테이블에서 멋대로 데이터를 변경할 수가 없게 되는 것이다.
 
아래는 락 종류에 따른 다른 트랜잭션 접근 시 호환성에 대한 표이다.
 

	S	IS	X	IX
S	호환 가능	호환 가능	충돌	충돌
IS	호환 가능	호환 가능	충돌	호환 가능
X	충돌	충돌	충돌	충돌
IX	충돌	호환 가능	충돌	호환 가능

기본적으로 표를 보면 IS의 경우 X, IX의 경우 S, X을 제외하고 여러 트랜잭션에서 동시에 사용이 가능하다.
 

---

 

💬 Record Lock (레코드 락)

레코드 락의 경우 레코드에 대해서 잠금을 거는 것이다.
innoDB의 경우 레코드 자체를 잠그는 것보다는, 인덱스의 레코드를 잠근다. 하지만, 인덱스가 없더라도 클러스터링 키를 내부적으로 생성해줬던 것처럼, 여기서도 클러스터 인덱스를 알아서 생성해주기 때문에 해당 인덱스를 레코드 잠금에 사용한다.

# id = 1인 레코드에 대해 S-Lock
SELECT id FROM tb_1 WHERE id = 1 LOCK IN SHARE MODE;

# id = 1인 레코드에 대해 X-Lock
SELECT id FROM tb_1 WHERE id = 1 FOR UPDATE;

 
레코드가 아닌 인덱스의 레코드에 대해 락을 거는 이유는 아래와 같다.

- innoDB의 B+ Tree 인덱스를 통해 데이터를 저장하거나 검색하는데, 이때 인덱스의 레코드를 탐색하여 특정 레코드를 찾아내기 때문에 인덱스의 레코드에 대한 접근이 필요하다.

- 또한, 인덱스에 대해서만 락을 걸기 때문에 다른 트랜잭션들이 접근하는 경우에도 충돌을 최소화하여 성능 자체에도 도움을 줄 수 있다.

 

---

 

💬 Gap Lock (갭 락)

갭 락의 경우 레코드가 아닌 레코드와 인접한 다른 레코드 사이의 간격을 잠그는 것을 의미한다. 이때, 첫 번째와 마지막 레코드 앞(Negative Infinity) 뒤(Positive Infinity)에 가상의 레코드가 있다고 가정하고 생성하는 것도 가능하다. 이러한 가상 레코드를 'Supremum' 가상 레코드라고 한다.
 
갭 락을 사용하게 되면, 조회 쿼리를 두 번 실행했을 때 다른 트랜잭션에서 수정이 발생하더라도 같은 결과가 리턴되도록 보장할 수 있다. 즉, Phantom Read를 방지하는 효과를 가진다. 이는 갭 락이 레코드 사이에 새로운 레코드가 삽입되는 것을 제어하는 것이기 때문이다.

select * from tb_1 where id between 1 and 10;

위와 같은 쿼리가 있을 때 1~10 사이에 X락이 걸리는 것과 동일하기 때문에, 새로운 데이터가 삽입되려면 대기해야 된다.
 
또한, 동일한 갭에 대해서 서로 다른 트랜잭션에서 충돌하는 락을 가질 수도 있다. 즉, 트랜잭션 A가 Gap S-Lock을 가지고 있고, 트랜잭션 B가 동일한 갭에 대해서 Gap X-Lock을 가질 수 있다. 이는 특정 레코드가 제거되었을 때 서로 다른 트랜잭션에서 해당 레코드에 가지고 있던 갭 락을 병합해야 하기 때문에 충돌이 허용하는 것이다.
 

💡 Where 절을 통해 데이터를 조회한 결과가 하나일 때, Record vs Gap 중 어떤 락이 사용될까?
- 기본적으로 컬럼에 unique index가 걸려 있다면 record lock이 사용된다.
- 인덱스가 없거나, unique 하지 않은 index라면 gap lock을 사용해야 한다.
: 인덱스가 있다면 쿼리 결과를 조회하기 위해 스캔한 인덱스 범위에 대해 gap lock이 적용되고, 인덱스가 없다면 테이블 전체를 스캔해야 하기 때문에 모든 레코드에 대해서 락이 걸린다.

 

---

 

💬 Next-Key Lock (넥스트 키 락)

레코드 락과 갭 락을 합친 형태를 넥스트 키 락이라고 한다.
innoDB에서는 테이블 인덱스를 검색하거나 스캔할 때 실제 인덱스 레코드에 대해 S / X-Lock을 설정하여 레코드 단위 락을 걸게 된다. 하지만, 넥스트 키 락의 경우 해당 인덱스 레코드 이전의 갭에도 영향을 미치기 때문에 하나의 세션이 특정 레코드 1번에 S / X-Lock을 걸면 다른 세션은 1번 바로 앞의 갭에 새로운 레코드를 생성할 수 없게 된다.
 

예를 들어, 10, 11, 13, 20에 인덱스가 걸려 있다면 아래와 같은 구간에서 락이 생성된다.
- (Negative infinity, 10]
- (10, 11]
- (11, 13]
- (13, 20]
- (20, Positive infinity)

 
잘 이해가 되지 않을 수도 있으니, 예시를 들어보자. 아래는 crew 테이블에 대해 id가 100 이상인 레코드를 조회하는 쿼리이다.

SELECT * FROM crew WHERE id > 100 FOR UPDATE;

이때, id > 100을 만족하는 id = 101인 리코드를 발견하면, 해당 레코드 직전의 레코드와 그 사이 락이 걸린다. (50 ~ 101 사이 갭 락)
이후, id > 100을 만족하는 레코드에 대해서도 갭 락과 레코드 락이 걸리게 되며, 이때 id = 150이 최대이기 때문에 Positive Infinity Gap Lock이 걸리게 된다.
 
넥스트 키 락의 경우 바이너리 로그가 기록되는 쿼리가 레플리카 서버에서 실행될 때, 기존 서버에서 만들어낸 결과와 동일한 결과를 만들어내도록 보장하는 것이 주 목적이다. 로그 포맷의 경우 statement, row, mixed로 나누어지는데, 아래와 같은 특징을 가진다.
 
- statement: 가장 오래된 포맷, 데이터 변경으로부터 사용되는 모든 쿼리를 저장
- row : 변경된 모든 레코드에 대한 정보 기록
- mixed: statement + row를 혼합하여 사용하는 방법
 
기존에는 statement 포맷의 바이너리 로그를 사용하는 것이 보편적이었으나, 이 경우 repeatable-read 이상의 격리 수준을 사용해야 한다는 점과 (read-committed 사용 시 실행 시점마다 결과가 달라질 수 있어서) 쿼리의 실행마다 결과가 달라지는 경우 (사용자 정의 함수, 프로시저 사용 등) 해당 쿼리는 사용할 수 없었다는 단점이 있었다. 또한, 넥스트 키 락과 갭 락으로 인해 데드락이 발생할 수 있으니 바이너리 로그 포맷을 ROW 형태로 바꿔서 락 자체를 줄이는 것이 좋다. (MySQL 8.0부터는 ROW 포맷의 바이너리 로그가 기본이다.)
 

---

 

💬 Insert Intention Lock (삽입 의도 락)

삽입 의도 락은 INSERT 구문이 실행될 때 묵시적으로 설정되는 일종의 갭 락이다.
여러 개의 트랜잭션이 갭 내부의 서로 다른 위치에 삽입을 진행하려고 할 때 대기 없이 실행되도록 하는 것이 목적이다. 기본적으로 삽입 의도 락들끼리는 충돌이 발생하지 않기 때문이다.
 
만약 id = 3, 7인 레코드가 있을 때 트랜잭션 A는 id = 5를, 트랜잭션 B는 id = 4을 삽입하는 상황을 가정해보자.

기본적인 갭 락을 걸었다면 트랜잭션 A가 5를 삽입하는 과정에서 이전 레코드인 3 ~ 5 사이에 갭 락이 걸릴 것이다. 이때, 트랜잭션 B가 id = 4을 삽입하려고 했을 때 이미 3~5 사이에 갭락이 걸려 있기 때문에 종료될 때까지 기다려야 해서 대기 시간이 존재한다.
 
반면에, 삽입 의도 락을 걸었다면 트랜잭션 A가 5를 삽입하는 과정에서 3 ~ 5 사이에 삽입 의도 락이 걸린다. 이때, 트랜잭션 B가 id = 4를 삽입하려고 할 때 삽입 의도 락은 충돌이 가능하기 때문에 대기 시간 없이 바로 삽입이 가능해진다.
 
삽입을 위한 X-Lock을 얻기 위해 삽입 의도 락을 통해서 묵시적으로 락을 걸어두게 된다.
 

---

 

💬 Auto-increment Lock (자동 증가 락)

MySQL에서는 auto_increment라는 컬럼을 통해서 자동으로 증가하는 값을 관리할 수 있다.
auto_increment가 사용된 테이블에 여러 개의 레코드가 삽입되는 경우, auto_increment 역시 일관성있게 증가해야 한다. 이를 위해서 innoDB에서는 자동 증가 락을 통해 (테이블 레벨 락) 관리한다.
 
자동 증가 락의 경우 기본적으로 insert, replace 같이 새로운 레코드를 삽입하는 쿼리에서만 필요하며, auto_increment 값을 가져오는 순간에만 락이 걸렸다가 즉시 해제된다. 테이블당 단 1개만 존재하기 때문에, 2개의 insert문이 동시에 실행되는 경우 나머지 하나는 락이 해제될 때까지 기다려야 한다.
 
명시적으로 자동 증가 락은 획득하고 해제하는 방법은 없지만, 어차피 엄청 짧은 시간 동안 걸렸다가 해제하기 때문에 크게 영향은 없다. MySQL 5.1부터는 어떤 식으로 자동 증가 락을 설정할지 시스템 변수로 관리도 가능하다.

- innodb_autoinc_lock_mode = 0 
모든 INSERT 문장은 자동 증가 락을 사용한다. 이때, 테이블 수준의 락을 적용한다.

- innodb_autoinc_lock_mode = 1 (MySQL 5.x 기본 값)
Bulk Inert 사용 시 테이블 레벨의 자동 증가 락을 사용하고, 명령문이 끝날 때까지 이를 유지하게 된다.
INSERT ... SELECT, REPLACE ... SELECT, LOAD DATA 같은 구문에서 사용한다.
하지만, 만약 삽입될 레코드의 수를 미리 알고 있다면, 래치 (뮤텍스) 제어 하에 필요한 수만큼의 자동 증가 값을 얻어서 수행되며, 테이블 레벨의 잠금을 방지한다. 

레코드 건수를 정확하게 알 수 없는 경우에는 모든 자동 증가 값이 연속적인 값이 되기 때문에 안전하게 사용이 가능하다.
그러나, Mixed-mode insert의 경우 삽입할 행의 수보다 더 큰 자동 증가 값을 할당될 수 있음을 유의해야 한다.
ex) insert into tb_1 values (1, 'A'), (NULL, 'B') 
- 이런 식으로 null 값이 혼합하여 들어가는 경우.

- innodb_autoinc_lock_mode = 2 (MySQL 8.0 기본값)
자동 증가 락을 절대 사용하지 않고 무조건 래치(뮤텍스)를 사용한다. auto_increment 값의 유니크성 / 단조 증가성을 보장한다.
대량의 삽입 쿼리가 실행될 때 다른 트랜잭션에서도 INSERT를 수행할 수 있기 때문에 동시 처리 성능은 높아진다. (여러 명령문이 동시에 숫자를 생성할 수 있음) 하지만, 단건 삽입의 경우 auto_increment 값 사이의 갭이 존재하지 않지만 여러 개가 삽입될 경우 갭이 존재할 수 있다. 

이러한 자동 증가 락으로 인해 auto_increment의 값은 기본적으로 한 번 증가하면 절대 줄어들지 않는 것을 기본으로 한다.
 

---

 
Predicate Locks for Spatial Indexes의 경우 공간 인덱싱을 지원한다고 하는데, 이해하기 어려워서 우선 패스...!
내용이 어려워서 알듯말듯한 것 같다.
 
다음 포스팅에서는 인덱스와 락의 관계 + 격리 수준에 대해서 알아보도록 하자!