운영체제 미드레벨 데이터베이스 기술면접

복합 인덱스의 컬럼 순서는 카디널리티가 높은(중복이 적은) 컬럼을 앞에 배치하는 것이 일반적이며, 쿼리의 WHERE 절에서 등호(=) 조건으로 사용되는 컬럼을 범위 조건보다 앞에 두어야 합니다. 예를 들어 이메일(고유값)은 앞에, 가입일자(범위 검색)는 뒤에 배치합니다. 인덱스 사용 여부는 EXPLAIN 또는 EXPLAIN ANALYZE 명령으로 실행 계획을 확인하여 Index Scan이 발생하는지, Full Table Scan이 발생하는지 검증할 수 있습니다. 또한 인덱스 힌트를 사용하여 옵티마이저의 선택을 강제하거나, 실제 쿼리 실행 시간과 I/O 비용을 프로파일링하여 성능을 측정해야 합니다. 복합 인덱스는 leftmost prefix 규칙을 따르므로, 첫 번째 컬럼 없이 두 번째 컬럼만 사용하는 쿼리에서는 인덱스가 활용되지 않는다는 점도 고려해야 합니다.

비관적 락은 SELECT FOR UPDATE 구문을 사용하여 트랜잭션이 시작될 때 해당 행에 배타적 락을 걸어 다른 트랜잭션의 접근을 차단하는 방식으로, 데이터 일관성을 보장하지만 동시성이 낮아지고 데드락 위험이 있습니다. 낙관적 락은 버전 컬럼(version)이나 타임스탬프를 사용하여 UPDATE 시점에 버전을 비교해 충돌을 감지하고, 충돌 발생 시 트랜잭션을 롤백하고 재시도하는 방식으로, 동시성은 높지만 충돌이 빈번하면 재시도 비용이 증가합니다. 트래픽이 높고 충돌이 빈번한 인기 상품의 경우 비관적 락이 적합하며, 충돌이 드문 일반 상품은 낙관적 락으로 높은 처리량을 확보하는 것이 유리합니다. 또한 데이터베이스 수준의 락 외에도 Redis 같은 분산 락을 활용하거나, 재고를 미리 예약하는 방식의 아키텍처 변경도 고려할 수 있습니다. SERIALIZABLE 격리 수준으로 변경하면 Lost Update는 방지되지만 성능 저하가 크므로 실무에서는 적절한 락 전략 선택이 중요합니다.

먼저 EXPLAIN ANALYZE로 실행 계획을 확인하여 Full Table Scan, Nested Loop Join 등 비효율적인 부분을 식별하고, 조인 키와 WHERE 절 컬럼에 적절한 인덱스가 있는지 확인합니다. 조인 순서를 최적화하여 작은 결과셋을 먼저 생성하도록 하고, 필요시 STRAIGHT_JOIN 힌트로 조인 순서를 명시할 수 있습니다. 월별 집계처럼 자주 조회되는 통계 데이터는 materialized view나 summary table을 생성하여 미리 집계해두고, 배치 작업으로 주기적으로 갱신하는 방식으로 실시간 쿼리 부하를 줄일 수 있습니다. 파티셔닝을 활용하여 날짜 기준으로 테이블을 분할하면 필요한 파티션만 스캔하여 I/O를 대폭 줄일 수 있습니다. 또한 SELECT 절에서 불필요한 컬럼을 제거하고, GROUP BY 전에 WHERE 절로 데이터를 충분히 필터링하며, 서브쿼리 대신 JOIN을 사용하는 등 쿼리 구조 자체를 개선하는 것도 중요합니다.