MySQL 복합 인덱스, 같은 컬럼인데 순서만 바꾸면 왜 느릴까?
같은 세 컬럼으로 만든 복합 인덱스라도 순서에 따라 확인하는 인덱스 항목 수가 14개에서 82,286개까지 달라집니다. MySQL 8.4에서 컬럼 순서만 바꾼 인덱스로 같은 쿼리를 실행하며 등호와 범위 조건, 인덱스 컨디션 푸시다운, 다른 쿼리와 함께 쓰는 순서, 정렬을 직접 확인합니다.
같은 세 컬럼으로 만든 복합 인덱스라도 순서에 따라 확인하는 인덱스 항목 수가 14개에서 82,286개까지 달라집니다. MySQL 8.4에서 컬럼 순서만 바꾼 인덱스로 같은 쿼리를 실행하며 등호와 범위 조건, 인덱스 컨디션 푸시다운, 다른 쿼리와 함께 쓰는 순서, 정렬을 직접 확인합니다.
REPEATABLE READ에서 잠금 읽기는 행 사이 빈 구간까지 잠가서, 아무도 쓰지 않는 번호를 INSERT해도 기다릴 수 있습니다. MySQL 8.4에서 data_locks로 갭 락을 직접 보고, 그 때문에 생기는 deadlock과 READ COMMITTED에서 달라지는 점을 확인합니다.
MySQL 8.4의 컬럼 추가는 대부분 순식간에 끝나지만, 열린 트랜잭션 하나가 있으면 ALTER TABLE이 메타데이터 락을 기다리고 그 뒤의 SELECT까지 함께 멈춥니다. 메타데이터 락 대기가 생기는 과정과 lock_wait_timeout으로 대기를 제한하는 방법을 직접 확인합니다.
Replica는 Source에서 받은 Binlog 이벤트를 Relay log에 먼저 쌓아 두고 따로 적용합니다. Relay log 안의 이벤트를 Binlog와 비교하고, 적용이 막히면 Relay log가 어떻게 쌓이고 언제 지워지는지 MySQL 8.4 Source와 Replica로 직접 확인합니다.

InnoDB는 바뀐 페이지를 바로 디스크에 쓰지 않고, redo log를 먼저 남겨 크래시 뒤에 다시 적용합니다. checkpoint가 어떻게 따라오는지, SIGKILL 뒤 redo를 얼마나 다시 적용하는지, 크래시 뒤 redo log를 지우면 어떻게 되는지 MySQL 8.4에서 직접 확인합니다.
InnoDB는 행을 바꾸기 전 상태를 undo log에 남겨 ROLLBACK과 과거 버전 읽기에 씁니다. SAVEPOINT, 오래된 스냅숏이 따라가는 버전 체인, 긴 트랜잭션 때문에 커지는 undo 테이블스페이스를 MySQL 8.4에서 직접 확인합니다.
Lock wait timeout(1205)은 deadlock(1213)과 달리 기본 설정에서 현재 문장만 롤백해서, 트랜잭션이 앞 문장의 변경과 잠금을 쥔 채 열려 있습니다. 두 오류가 끝나는 시점과 롤백 범위의 차이를 MySQL 8.4에서 직접 확인합니다.
UPDATE 하나를 실행하면 MySQL은 binlog, redo log, undo log에 함께 기록합니다. 세 로그를 언제 쓰고 누가 왜 읽는지, 커밋과 스냅숏 읽기, 크래시 복구 과정에서 MySQL 8.4로 직접 확인합니다.
MySQL은 커밋된 변경을 Binlog에 이벤트로 남기고, 복제와 특정 시점 복구, CDC가 모두 이 기록을 읽습니다. MySQL 8.4에서 Binlog 이벤트와 바뀐 행의 값을 직접 읽고, STATEMENT 형식에서 Source와 Replica의 값이 달라지는 경우를 확인합니다.
Slow query log에 남은 쿼리가 모두 고쳐야 할 쿼리는 아닙니다. MySQL 8.4에서 기록 기준과 네 가지 단서를 확인하고, 총 영향과 실행 계획으로 먼저 고칠 쿼리를 고르는 과정을 직접 따라가 봅니다.

서버가 켜지지 않거나 갑자기 재시작됐을 때 원인은 Error log에 남습니다. MySQL 8.4에서 로그 파일 권한 오류, 설정 이름 오타, SIGKILL 크래시를 직접 만들어 보고 Error log를 어디까지, 어떤 순서로 읽어야 하는지 확인합니다.
Deadlock이 나면 InnoDB는 바꾼 행이 적은 트랜잭션을 골라 롤백합니다. 어떤 트랜잭션이 롤백되는지, 기록은 어디서 읽는지, 애플리케이션은 어떻게 다시 시도해야 하는지 MySQL 8.4에서 직접 확인합니다.
애플리케이션이 보냈다고 믿는 SQL과 MySQL이 실제로 받은 SQL은 다를 수 있습니다. MySQL 8.4에서 General log를 켜고 기록을 읽어 보고, 개인정보가 그대로 남고 연결이 잦을수록 로그가 빨리 쌓여 운영 서버에서 계속 켜 두면 안 되는 이유를 직접 확인합니다.

로그를 오래 남길수록 디스크가 먼저 찹니다. Binlog의 기본 보관 기간과 Replica가 아직 읽지 않은 Binlog를 지웠을 때 생기는 오류 13114, General log가 쌓이는 양을 MySQL 8.4 Source와 Replica로 직접 확인해 봅니다.
폴링 대신 Binlog를 읽어 DB 변경을 Kafka 이벤트로 보내는 CDC를 MySQL 8.4, Debezium, Kafka로 직접 따라갑니다. 커넥터를 등록하고 UPDATE 한 줄이 바뀌기 전과 뒤 값을 함께 담은 이벤트가 되는 과정을 확인합니다.

백업만으로는 사고 직전의 데이터를 되살릴 수 없습니다. MySQL 8.4에서 Binlog 위치를 찾아 실수로 지운 주문을 복구하는 과정을 직접 따라 해 봅니다.
