MySQL 미드레벨 기술면접

WHERE 절에서 컬럼에 함수를 적용하면 인덱스의 정렬 순서를 활용할 수 없어 풀 테이블 스캔이 발생합니다. DATE(created_at) = '2024-01-01'은 모든 행의 created_at 값을 DATE 함수로 변환한 후 비교해야 하므로 인덱스를 사용할 수 없습니다. 이를 개선하려면 created_at >= '2024-01-01 00:00:00' AND created_at < '2024-01-02 00:00:00' 처럼 컬럼을 가공하지 않고 범위 조건으로 변경해야 합니다. 또는 Function-Based Index나 Generated Column을 활용하여 함수 결과값에 대한 인덱스를 생성할 수도 있습니다.

SELECT ... FOR UPDATE는 배타적 잠금(Exclusive Lock)을 획득하여 다른 트랜잭션의 읽기와 쓰기를 모두 차단합니다. SELECT ... FOR SHARE는 공유 잠금(Shared Lock)을 획득하여 다른 트랜잭션의 읽기는 허용하지만 쓰기는 차단합니다. FOR UPDATE는 재고 차감처럼 읽은 후 반드시 수정할 데이터에 사용하며, FOR SHARE는 참조 무결성 검증처럼 읽은 데이터가 변경되지 않아야 하지만 여러 트랜잭션이 동시에 읽을 수 있어야 하는 경우에 사용합니다. FOR SHARE를 사용하면 동시성이 높아지지만, 여러 트랜잭션이 공유 잠금을 획득한 상태에서 배타적 잠금으로 업그레이드하려 할 때 데드락이 발생할 수 있습니다.

카운터 컬럼을 두면 COUNT 쿼리 없이 빠르게 개수를 조회할 수 있지만, 자식 레코드 추가/삭제 시마다 부모 테이블을 UPDATE해야 하므로 쓰기 부하가 증가하고 부모 레코드에 잠금 경합이 발생합니다. 또한 애플리케이션 로직에서 카운터를 유지해야 하므로 데이터 불일치 위험이 있습니다. 동시성 문제를 해결하려면 UPDATE parent SET count = count + 1 같은 원자적 증감 연산을 사용하거나, Redis 같은 별도 저장소에서 카운터를 관리하고 주기적으로 동기화하는 방법이 있습니다. 또는 이벤트 기반 아키텍처로 비동기 업데이트를 수행할 수도 있습니다.

복제 지연의 주요 원인은 Master의 쓰기 부하가 높아 Binary Log가 빠르게 생성되는데 Slave가 Single Thread로 순차 적용하여 따라가지 못하는 경우, Slave에서 무거운 읽기 쿼리가 실행되어 리소스 경합이 발생하는 경우, 네트워크 대역폭 부족, 그리고 대용량 트랜잭션이 있습니다. 모니터링은 SHOW SLAVE STATUS의 Seconds_Behind_Master 값을 확인하거나 Percona Monitoring and Management(PMM) 같은 도구를 사용합니다. 해결 방법으로는 MySQL 5.7 이상에서 Multi-Threaded Slave(병렬 복제)를 활성화하고, Slave를 읽기 전용으로 분리하거나 스케일 아웃하며, 대용량 배치 작업을 작은 단위로 분할하고, 필요시 GTID 기반 복제로 전환하는 방법이 있습니다.

간헐적 성능 저하는 잠금 대기, 버퍼 풀 상태 변화, 통계 정보 변경, 디스크 I/O 경합 등 다양한 원인이 있습니다. 먼저 Performance Schema나 SHOW PROCESSLIST로 해당 시점의 잠금 대기 여부를 확인하고, InnoDB 버퍼 풀의 히트율 변화를 모니터링합니다. EXPLAIN 실행 계획이 시간에 따라 달라지는지 확인하여 통계 정보 변경 여부를 점검하고, 필요시 ANALYZE TABLE로 통계를 갱신합니다. 시스템 레벨에서는 iostat, vmstat으로 디스크 I/O 대기나 메모리 스왑 발생을 확인하며, 동일 시간대에 실행되는 배치 작업이나 백업 작업이 있는지 확인합니다. 쿼리 힌트나 optimizer_switch 설정으로 실행 계획을 고정하거나, 부하가 높은 시간대를 피해 작업을 스케줄링하는 방법으로 해결할 수 있습니다.