MySQL에서 사용되는 잠금은 MySQL Engine Lock과 Storage Lock으로 구분된다.
이 글에서는 Engine Lock에 대해 다뤄보려고 한다.

1. Global Lock

MySQL에서 제공하는 Lock 중에서 가장 범위가 넓다.
FLUSH TABLES WITH READ LOCK 명령으로 획득할 수 있다.
한 세션에서 Global Lock을 획득하면, 다른 세션에서 SELECT를 제외한 대부분의 DML/DDL 명령을 실행하는 경우,
글로벌 락이 해제될 때까지 해당 명령이 대기 상태로 남겨진다.
Global Lock이 영향이 미치는 범위는 MySQL 서버 전체이며, 작업 대상 테이블이나 데이터베이스가 달라도 영향이 동일하게 미친다.
여러 데이터베이스에 존재하는 MyISAM이나 MEMORY 테이블에 대해 mysqldump로 일관된 백업을 받을 때, Global Lock을 사용해야 한다.

MySQL 8.0에서 MySQL 스토리지 엔진이 InnoDB으로 채택되었다.
InnoDB는 트랜잭션을 지원하므로, 일관된 데이터 상태를 유지하기 위해, 모든 데이터 변경 작업을 멈출 필요가 없다.
그래서 MySQL 8.0부터는 Xtrabackup이나 Enterprise Backup과 백업 툴들의 안정적 실행을 위해 Backup Lock이 도입됐다.

Backup Lock을 획득하면, 테이블의 스키마나 사용자의 인증 관련 정보를 변경할 수 없다.

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

하지만 Backup Lock은 일반적인 테이블의 데이터 변경을 허용한다.

Backup Lock가 도입된 배경을 생각해보자.
MySQL 서버는 Primary/Replica로 구성되는데, 백업은 주로 Replica에서 진행된다.
백업이 Global Lock을 통해 이뤄진다면, Replica의 복제는 백업 시간만큼 지연될 수 밖에 없다.
>> 따라서 Global Lock이 아닌 다른 방법이 필요하다.
Replica 서버에서 백업을 실행하는 중에 Primary 서버에서 문제가 생기면, Replica 서버의 데이터가 최신 상태가 될 때까지 서비스를 멈춰야 할 수 있다.
XtraBackup이나 Enterprise Backup 툴은 복제가 진행되는 상황에서 일관된 백업을 만들 수 있다.
하지만 스키마 변경이 실행되면, 백업은 실패한다.
6~7시간 동안 백업이 실행되고 있는데, 갑자기 DDL 명령 하나로 인해 백업이 실패하면, 다시 그만큼 시간을 들여 백업을 실행해야 한다.
MySQL Backup Lock은 이런 목적으로 도입되었으며, 정상적으로 복제가 실행되지만, 백업의 실패를 막기 위해, DDL 명령이 실행되면, 복제를 일시중지하는 역할을 한다.

2. Table Lock

개별 테이블 단위로 설정되는 Lock이다.
명시적 또는 묵시적으로 특정 테이블의 Lock을 획득할 수 있다.
명시적으로 LOCK TABLES table_name [ READ | WRITE ] 명령으로 Table Lock을 획득한다.
UNLOCK TABLES 명령으로 명시적으로 획득한 잠금을 반납할 수 있다.

보통 Table Lock은 사용할 일이 없다.

묵시적 Table Lock은 MyISAM이나 MEMORY 테이블에 데이터를 변경하는 쿼리를 실행하면 발생한다.
MySQL 서버가 데이터가 변경되는 잠금을 설정하고 데이터를 변경한 뒤, 즉시 잠금을 해제하는 형태로 사용된다.
즉, 묵시적 Table Lock은 쿼리가 실행되는 동안 자동으로 획득됐다가 쿼리가 완료된 후 자동해제된다.

하지만 InnoDB 테이블의 경우, 스토리지 엔진 차원에서 레코드 기반 잠금을 제공하기 때문에,
단순 데이터 변경 쿼리로 인해 묵시적 Table Lock이 설정되지 않는다.
더 정확히는 InnoDB 테이블에도 Table Lock이 설정되지만 대부분의 데이터 변경 쿼리(DML)에서는 무시되고,
스키마를 변경하는 쿼리(DDL)의 경우에만 영향을 미친다.