MySQL 신입 개발자 기술면접
새 면접Q. MySQL에서 Primary Key와 Unique Key의 차이점을 설명해주세요.
NULL 값 허용 여부와 테이블당 개수 제한을 생각해보세요.
Primary Key는 테이블에서 각 레코드를 고유하게 식별하는 키로, NULL 값을 허용하지 않으며 테이블당 하나만 존재할 수 있습니다. Unique Key는 중복되지 않는 값을 보장하지만 NULL 값을 허용하며, 여러 개를 설정할 수 있습니다. Primary Key는 자동으로 클러스터드 인덱스가 생성되어 물리적 저장 순서를 결정합니다. 반면 Unique Key는 논클러스터드 인덱스로 생성됩니다. 실무에서는 Primary Key로 주요 식별자를, Unique Key로 이메일이나 전화번호 같은 중복 방지가 필요한 컬럼을 관리합니다.
- • Primary Key는 NULL 불가, 테이블당 1개
- • Unique Key는 NULL 허용, 여러 개 가능
- • Primary Key는 클러스터드 인덱스 생성
회원 테이블에서 회원ID는 Primary Key로, 이메일은 Unique Key로 설정하여 중복 가입을 방지합니다.
만약 Primary Key를 복합키(Composite Key)로 구성한다면 어떤 경우에 유용할까요?
Q. 사용자 목록을 조회하는 쿼리가 갑자기 느려졌습니다. 데이터는 처음 개발할 때보다 10배 이상 증가했고, WHERE 절에서 생성일자로 필터링하고 있습니다. 어떤 원인을 의심하고 어떻게 해결하시겠습니까?
데이터가 증가했을 때 조회 성능에 가장 큰 영향을 주는 것이 무엇인지 생각해보세요.
가장 먼저 생성일자 컬럼에 인덱스가 없는지 의심해봐야 합니다. EXPLAIN 명령어로 실행 계획을 확인하여 Full Table Scan이 발생하는지 점검합니다. 인덱스가 없다면 생성일자 컬럼에 인덱스를 추가하여 검색 성능을 개선할 수 있습니다. 또한 SELECT * 대신 필요한 컬럼만 조회하도록 쿼리를 수정하고, LIMIT을 활용한 페이징 처리를 고려합니다. 인덱스 추가 후에도 ANALYZE TABLE 명령으로 통계 정보를 갱신하여 옵티마이저가 최적의 실행 계획을 수립하도록 합니다.
- • EXPLAIN으로 실행 계획 확인
- • WHERE 절 컬럼에 인덱스 추가
- • SELECT 컬럼 최소화 및 페이징 처리
게시판 서비스에서 게시글이 수만 건으로 증가하면서 날짜별 조회가 느려질 때 인덱스 추가로 해결합니다.
인덱스를 추가했는데도 성능이 개선되지 않는다면 어떤 추가 원인을 확인해볼 수 있을까요?
Q. MySQL에서 트랜잭션(Transaction)이란 무엇이며, ACID 속성 중 원자성(Atomicity)에 대해 설명해주세요.
트랜잭션 내의 여러 작업이 실패했을 때 어떻게 처리되는지 생각해보세요.
트랜잭션은 데이터베이스에서 하나의 논리적 작업 단위로 실행되는 일련의 연산들을 의미합니다. 원자성(Atomicity)은 트랜잭션 내의 모든 작업이 전부 성공하거나 전부 실패해야 한다는 특성입니다. 예를 들어 계좌 이체 시 출금과 입금 두 작업 중 하나라도 실패하면 모든 작업이 롤백되어 이전 상태로 돌아갑니다. MySQL에서는 COMMIT으로 트랜잭션을 확정하고, ROLLBACK으로 취소할 수 있습니다. InnoDB 스토리지 엔진은 트랜잭션을 지원하지만 MyISAM은 지원하지 않습니다.
- • 트랜잭션은 논리적 작업 단위
- • 원자성은 All or Nothing 원칙
- • COMMIT과 ROLLBACK으로 제어
결제 시스템에서 주문 생성, 재고 차감, 포인트 적립을 하나의 트랜잭션으로 묶어 일관성을 보장합니다.
ACID의 나머지 속성인 일관성, 격리성, 지속성에 대해서도 간단히 설명해주실 수 있나요?
Q. INNER JOIN과 LEFT JOIN의 차이를 설명하고, 각각 어떤 상황에서 사용하는지 예시를 들어주세요.
두 테이블을 연결할 때 매칭되지 않는 레코드를 어떻게 처리하는지가 핵심입니다.
INNER JOIN은 두 테이블에서 조인 조건을 만족하는 레코드만 반환하며, 어느 한쪽에만 존재하는 데이터는 결과에 포함되지 않습니다. LEFT JOIN은 왼쪽 테이블의 모든 레코드를 반환하고, 오른쪽 테이블에 매칭되는 데이터가 없으면 NULL로 채웁니다. INNER JOIN은 주문 내역과 상품 정보를 조회할 때처럼 양쪽 데이터가 모두 존재해야 하는 경우에 사용합니다. LEFT JOIN은 전체 회원 목록과 주문 이력을 함께 조회할 때처럼, 주문하지 않은 회원도 포함해야 하는 경우에 사용합니다.
- • INNER JOIN은 매칭되는 레코드만 반환
- • LEFT JOIN은 왼쪽 테이블 전체 + 매칭 데이터
- • 용도에 따라 적절한 JOIN 선택 필요
고객 관리 시스템에서 모든 고객과 그들의 최근 구매 이력을 함께 보여줄 때 LEFT JOIN을 사용합니다.
RIGHT JOIN과 FULL OUTER JOIN도 있는데, MySQL에서 FULL OUTER JOIN을 구현하려면 어떻게 해야 할까요?
Q. 데이터베이스 인덱스(Index)가 무엇인지 설명하고, 인덱스를 사용하면 좋은 점과 주의해야 할 점을 말씀해주세요.
조회 성능과 데이터 수정 작업 사이의 트레이드오프를 생각해보세요.
인덱스는 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조로, 책의 색인과 같은 역할을 합니다. 인덱스를 사용하면 WHERE, ORDER BY, JOIN 등의 조회 성능이 크게 향상되어 Full Table Scan을 피할 수 있습니다. 하지만 인덱스는 별도의 저장 공간을 차지하며, INSERT, UPDATE, DELETE 시 인덱스도 함께 갱신해야 하므로 쓰기 성능이 저하될 수 있습니다. 따라서 자주 조회되는 컬럼에만 선택적으로 인덱스를 생성해야 하며, 카디널리티가 높은 컬럼에 생성하는 것이 효과적입니다. 과도한 인덱스는 오히려 성능을 저하시킬 수 있으므로 주의가 필요합니다.
- • 인덱스는 조회 성능 향상을 위한 자료구조
- • 쓰기 작업 시 성능 저하 가능
- • 선택적이고 적절한 인덱스 생성이 중요
전자상품 쇼핑몰에서 카테고리별 상품 검색이 빈번하다면 카테고리 컬럼에 인덱스를 생성하여 조회 속도를 개선합니다.
복합 인덱스(Composite Index)를 생성할 때 컬럼 순서가 중요한 이유는 무엇일까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!