1. 레코드 락 ( 중요! )

( https://20201111start.tistory.com/entry/MySQL-%EB%9D%BDLock-%EC%9D%B4%EB%9E%80 )

first_name='DK'가 250건 조회 + 해당 컬럼에만 "보조 인덱스" 적용

-> 250건 다 락 걸림.

테이블의 레코드가 아니라!, 인덱스의 레코드를 잠근다.

만약 적당한 인덱스가 없다면 모든 테이블의 레코드에 락을 걸고, 테이블을 풀스캔 하면서 작업을 처리 -> 동시성 매우 심각.

(단, SELECT를 제외한 UPDATE, DELETE에서만 유효)

2. 갭 락

(오직 인덱스 기반의 범위 검색에서만 발생)

-- 배타락 or 공유락에서 발생.
SELECT * FROM member WHERE last_name LIKE 'J%' FOR UPDATE;

• last_name에 인덱스가 있다면

• J%로 시작하는 레코드 범위 전체에 Next-Key Lock

• 'I'와 'J' 사이의 갭

• 'J' ~ 'K' 사이의 갭

• 결과적으로 J로 시작하는 레코드뿐 아니라,
  J~K 사이에 새로운 레코드가 삽입되지 못하게 막음 (갭락)

last_name	잠금 종류
'Isaac'	갭락 (I~J 사이)
'Jack'	Next-Key Lock
'James'	Next-Key Lock
'Jason'	Next-Key Lock
'Kevin'	갭락 (J~K 사이)

-> 팬텀리드 방지

3. 넥스트 키 락

( 레코드 락 + 갭 락 )

갭 락이나 넥스트 키 락은 바이너리 로그에 기록되는 쿼리가 리플리카 서버에서 실행될 때 소스 서버에서 만들어낸 결과와 동일한 결과를 만들어내도록 보장해주는 것이 주목적이라고 한다.

그런데 의외로 넥스트 키 락과 갭 락으로 인해 데드락이 발생하거나 다른 트랜잭션이 기다리는 일이 자주 발생하므로,
바이너리 로그 포맷을 ROW 형태로 바꿔서 넥스트 키 락이나 갭 락을 줄이는 것이 좋다고 한다.

4. 자동 증가 락

( 자동 증가하는 숫자값을 채번하기 위해 AUTO_INCREMENT 컬럼 속성을 사용, 주로 대체키에 사용 )

• 여러 레코드가 동시에 INSERT 되더라도 "중복되지 않고 순차적으로 증가하는 일련번호를 제공하기 위해서 내부적으로 테이블 수준의 잠금인 자동 증가 락을 사용"

• 새로운 레코드를 저장하는 쿼리에서만 사용.

• 자동 증가 락은 테이블에 1개만 존재 -> 한 쿼리에서 락을 획득해서 채번중이면, 다음 쿼리는 락을 대기