MySQL 미드레벨 CS 기초 면접
새 면접Q. MySQL InnoDB에서 MVCC(Multi-Version Concurrency Control)의 동작 원리를 설명하고, 이것이 어떻게 락 없이 읽기 작업의 동시성을 향상시키는지 설명해주세요.
MVCC는 데이터의 여러 버전을 유지하여 읽기와 쓰기 작업이 서로 블로킹하지 않도록 하는 메커니즘입니다. InnoDB는 Undo Log에 이전 버전의 데이터를 저장하고, 각 트랜잭션은 자신의 시작 시점에 대한 스냅샷을 기준으로 데이터를 읽습니다. 쓰기 트랜잭션이 데이터를 변경하더라도 읽기 트랜잭션은 Undo Log를 통해 자신의 스냅샷 시점의 데이터를 조회할 수 있어, 읽기 작업에 락이 필요하지 않습니다. 이를 통해 높은 동시성을 유지하면서도 격리 수준을 보장할 수 있습니다.
- • 데이터의 여러 버전을 Undo Log에 저장하여 관리
- • 각 트랜잭션은 시작 시점의 스냅샷을 기준으로 읽기 수행
- • 읽기 작업이 쓰기 작업을 블로킹하지 않아 동시성 향상
- • 트랜잭션 ID와 롤백 포인터를 통해 적절한 버전 선택
MVCC 환경에서 Undo Log가 과도하게 증가하는 상황과 이로 인한 문제, 그리고 해결 방법을 설명해주세요.
Q. MySQL 옵티마이저가 쿼리 실행 계획을 수립할 때 사용하는 비용 기반 최적화(Cost-Based Optimization) 방식을 설명하고, 통계 정보가 부정확할 때 발생할 수 있는 문제와 해결 방법을 설명해주세요.
비용 기반 최적화는 각 실행 계획의 예상 비용을 계산하여 가장 낮은 비용의 계획을 선택하는 방식입니다. 옵티마이저는 테이블의 행 수, 인덱스 카디널리티, 데이터 분포 등의 통계 정보를 활용하여 디스크 I/O, CPU 사용량 등의 비용을 추정합니다. 통계 정보가 오래되거나 부정확하면 옵티마이저가 잘못된 인덱스를 선택하거나 비효율적인 조인 순서를 결정할 수 있습니다. 이를 해결하기 위해 ANALYZE TABLE로 통계를 갱신하거나, 옵티마이저 힌트를 사용하거나, innodb_stats_persistent 설정을 조정하여 통계의 정확도를 높일 수 있습니다.
- • 테이블 통계 정보를 기반으로 각 실행 계획의 비용 추정
- • 디스크 I/O, CPU 비용 등을 종합하여 최적 계획 선택
- • 부정확한 통계는 잘못된 인덱스 선택이나 조인 순서 결정 유발
- • ANALYZE TABLE, 옵티마이저 힌트, 통계 설정 조정으로 해결
MySQL 8.0에서 도입된 히스토그램(Histogram) 통계가 기존 통계 정보와 어떻게 다르며, 어떤 상황에서 쿼리 최적화에 도움이 되는지 설명해주세요.
Q. MySQL InnoDB에서 사용하는 페이지(Page) 단위 저장 구조를 설명하고, 페이지 크기가 쿼리 성능과 저장 공간 효율성에 미치는 영향을 설명해주세요.
InnoDB는 데이터를 페이지 단위로 관리하며, 기본 페이지 크기는 16KB입니다. 페이지는 디스크 I/O의 최소 단위로, 하나의 행만 읽더라도 해당 페이지 전체를 메모리로 로드합니다. 페이지 크기가 크면 한 번의 I/O로 더 많은 데이터를 읽을 수 있어 순차 읽기 성능이 향상되지만, 작은 데이터를 읽을 때는 불필요한 데이터까지 로드되어 비효율적입니다. 페이지 크기가 작으면 랜덤 액세스가 많은 OLTP 환경에서 유리하지만, B+Tree의 깊이가 증가하여 인덱스 탐색 비용이 커질 수 있습니다. 따라서 워크로드 특성에 따라 적절한 페이지 크기를 선택해야 합니다.
- • InnoDB는 16KB 페이지 단위로 데이터를 관리하며 디스크 I/O의 최소 단위
- • 큰 페이지는 순차 읽기에 유리하나 랜덤 액세스 시 비효율적
- • 작은 페이지는 OLTP에 유리하나 B+Tree 깊이 증가
- • 워크로드 특성에 따라 innodb_page_size 설정 필요
SSD와 HDD 환경에서 페이지 크기 선택 전략이 어떻게 달라져야 하는지 설명해주세요.
Q. MySQL 클라이언트와 서버 간 통신 프로토콜의 특징을 설명하고, Prepared Statement가 일반 쿼리 대비 네트워크 트래픽과 파싱 비용을 절감하는 원리를 설명해주세요.
MySQL은 TCP/IP 기반의 클라이언트-서버 프로토콜을 사용하며, 텍스트 기반과 바이너리 기반 프로토콜을 모두 지원합니다. Prepared Statement는 쿼리 템플릿을 먼저 서버에 전송하여 파싱과 최적화를 수행한 후, 실행 시에는 파라미터 값만 바이너리 형태로 전송합니다. 이를 통해 매번 전체 SQL 문자열을 전송하지 않아 네트워크 트래픽이 감소하고, 서버는 이미 파싱된 실행 계획을 재사용하여 파싱 비용을 절감할 수 있습니다. 또한 바이너리 프로토콜은 데이터 타입 변환이 효율적이며, SQL 인젝션 방어에도 효과적입니다.
- • 쿼리 템플릿을 사전에 전송하고 파라미터만 바이너리로 전송하여 트래픽 감소
- • 서버가 파싱된 실행 계획을 캐싱하여 재사용하므로 파싱 비용 절감
- • 바이너리 프로토콜로 데이터 타입 변환 효율성 향상
- • SQL 인젝션 방어 효과 제공
Connection Pool 환경에서 Prepared Statement를 사용할 때 주의해야 할 점과 서버 측 Prepared Statement 개수 제한 문제를 설명해주세요.
Q. MySQL의 논리적 백업(Logical Backup)과 물리적 백업(Physical Backup)의 차이점을 설명하고, 각각의 백업 방식이 적합한 상황과 복구 시간(RTO), 복구 시점(RPO) 관점에서의 트레이드오프를 설명해주세요.
논리적 백업은 mysqldump 등을 사용하여 SQL 문 형태로 데이터를 추출하는 방식이며, 물리적 백업은 데이터 파일 자체를 복사하는 방식입니다. 논리적 백업은 플랫폼 독립적이고 선택적 복구가 가능하지만, 백업과 복구 시간이 오래 걸려 대용량 데이터베이스에는 부적합합니다. 물리적 백업은 파일 복사 방식으로 빠르며, Percona XtraBackup 등을 사용하면 온라인 백업이 가능하여 서비스 중단 없이 백업할 수 있습니다. RTO 관점에서 물리적 백업이 훨씬 빠른 복구를 제공하며, RPO는 바이너리 로그를 함께 사용하면 두 방식 모두 특정 시점으로 복구 가능합니다. 대용량 프로덕션 환경에서는 주로 물리적 백업을 사용하고, 논리적 백업은 부분 복구나 마이그레이션 용도로 활용합니다.
- • 논리적 백업은 SQL 문 형태, 물리적 백업은 데이터 파일 복사
- • 논리적 백업은 유연하나 느리고, 물리적 백업은 빠르나 플랫폼 종속적
- • 물리적 백업이 RTO 측면에서 압도적으로 유리
- • 바이너리 로그 조합으로 Point-in-Time Recovery 구현 가능
증분 백업(Incremental Backup)과 차등 백업(Differential Backup)의 차이를 설명하고, MySQL 환경에서 바이너리 로그를 활용한 증분 백업 전략을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!