고약한 알바트로스님의 면접 결과

인덱스의 기본 개념과 목적, 그리고 적용 시점에 대해 정확하게 설명해주셨고, B-tree와 해시 등 주요 자료구조도 언급해주신 점이 좋습니다. 다만 질문에서 "어떤 자료구조로 구현할 수 있나요?"라고 물었는데, 각 자료구조의 특징이나 차이점에 대한 설명이 부족했습니다. 예를 들어 B-tree는 범위 검색에 유리하고 해시 인덱스는 등가 검색에 빠르다는 점, 또는 실제 MySQL의 InnoDB에서 B+tree를 사용한다는 구체적인 예시를 추가하시면 더욱 완성도 높은 답변이 될 것 같습니다. 앞으로는 자료구조별 특성과 실제 DBMS에서의 구현 방식에 대해 더 학습해보시길 권합니다.

B-tree 인덱스와 해시 인덱스의 핵심적인 차이점을 정렬 상태와 연결지어 잘 설명해주셨고, 각각의 장점도 명확하게 구분해서 답변해주신 점이 좋았습니다. 다만 답변을 더욱 완성도 있게 만들려면 구체적인 시간복잡도 차이(해시 인덱스 O(1) vs B-tree 인덱스 O(log n))와 해시 인덱스의 단점들(범위 검색 불가, ORDER BY 지원 불가 등)을 추가로 언급하시면 좋겠습니다. 또한 실제 데이터베이스에서 B-tree가 더 널리 사용되는 이유나 해시 인덱스가 메모리 기반 스토리지 엔진에서 주로 활용되는 점 등의 실무적 맥락을 덧붙이시면 더욱 깊이 있는 답변이 될 것 같습니다. 전반적으로 핵심 개념은 정확하게 이해하고 계시니, 좀 더 세부적인 특성들과 실무 활용 사례를 학습해보시길 권합니다.

인덱스 성능 저하 상황에 대해 핵심적인 부분들을 잘 파악하고 계시네요. 특히 DML 작업 시 인덱스 갱신으로 인한 오버헤드와 메모리 사용량 증가, 옵티마이저의 잘못된 인덱스 선택 등 주요 원인들을 정확하게 언급해주셨습니다. 다만 답변에서 언급하신 해결책 부분이 상대적으로 부족했는데, 인덱스 힌트 사용, 복합 인덱스 순서 최적화, 사용하지 않는 인덱스 제거, 통계 정보 업데이트 등의 구체적인 해결 방안들을 추가로 학습하시면 좋겠습니다. 또한 카디널리티가 낮은 컬럼에 인덱스를 생성했을 때의 비효율성이나, 인덱스 스캔보다 풀 테이블 스캔이 더 효율적인 경우(작은 테이블, 대부분의 데이터를 조회하는 경우 등)에 대한 구체적인 예시도 함께 설명할 수 있다면 더욱 완성도 높은 답변이 될 것 같습니다.

옵티마이저가 I/O 비용을 기준으로 실행 계획을 결정한다는 점과 힌트를 통해 제어할 수 있다는 기본적인 개념은 맞습니다. 하지만 답변이 너무 간략해서 질문에서 요구한 핵심 내용들이 많이 누락되었습니다. 옵티마이저가 고려하는 요소로는 I/O 비용 외에도 통계 정보(카디널리티, 선택도), CPU 비용, 메모리 사용량 등이 있으며, 제어 방법으로는 힌트 외에도 통계 정보 갱신, 인덱스 재구성, 쿼리 재작성 등 다양한 방법이 있습니다. 옵티마이저의 동작 원리와 비용 기반 최적화(CBO)에 대해 더 깊이 학습하시면 좋겠습니다.