Docs : 면접 예상 질문 취합 및 정리

Author: co2plant

77-Interview/01-Database_면접예상질문.md

@@ -225,3 +225,80 @@
     Dirty Read	Unrepeatable Read	Phantom Read 모두 발생하지 않습니다
     </details>
 </details>
+
+
+
+<summary><h3>데이터베이스에서 인덱스를 사용하는 이유와 장단점에 대해 설명해주세요.(DB)</h3></summary>
+**인덱스(Index)** 는 데이터베이스 테이블의 ** 검색(SELECT) 성능을 향상시키기 위한 자료구조**입니다. 책의 맨 뒤에 있는 '찾아보기'와 같은 역할을 합니다.
+
+*   **사용 이유:** 인덱스가 없으면 특정 데이터를 찾기 위해 테이블 전체를 스캔해야 합니다(Full Table Scan). 하지만 인덱스를 사용하면 데이터가 정렬된 상태로 저장된 별도의 자료구조를 통해 원하는 데이터의 위치(주소)를 빠르게 찾아낼 수 있어 검색 속도가 비약적으로 향상됩니다.
+
+**장점:**
+*   **빠른 검색 속도:** `WHERE` 절이나 `JOIN` 작업의 성능을 크게 향상시킵니다.
+*   **정렬 속도 향상:** `ORDER BY` 작업 시, 이미 정렬된 인덱스를 활용할 수 있어 추가적인 정렬 과정이 필요 없을 수 있습니다.
+*   **UNIQUE 제약조건 강화:** Primary Key나 Unique 인덱스를 통해 데이터의 유일성을 보장할 수 있습니다.
+
+**단점:**
+*   **쓰기 성능 저하:** 데이터에 `INSERT`, `UPDATE`, `DELETE` 작업이 발생할 때마다 인덱스 테이블도 함께 수정되어야 하므로 쓰기 성능이 저하됩니다.
+*   **추가 저장 공간 필요:** 인덱스는 원본 테이블과는 별도의 저장 공간을 차지합니다. (테이블 크기의 약 10% 내외)
+*   **잘못된 사용 시 성능 저하:** 인덱스를 잘못 설계하면 오히려 사용되지 않거나(Unused Index), 옵티마이저가 잘못된 인덱스를 선택하여(Wrong Index) 성능이 더 나빠질 수 있습니다. 따라서 카디널리티(Cardinality, 중복도)가 높은 컬럼에 생성하는 것이 좋습니다.
+    <details>
+    <summary><h4>꼬리질문 1: 인덱스의 자료구조로는 보통 어떤 것을 사용하나요? B-Tree와 B+Tree의 차이점에 대해 설명해주세요.</h4></summary>
+    인덱스의 자료구조로는 주로 **B-Tree(Balanced Tree)** 가 사용되며, 특히 InnoDB 스토리지 엔진을 사용하는 MySQL/MariaDB에서는 **B+Tree** 가 사용됩니다.
+
+*   **B-Tree:**
+    -   하나의 노드에 여러 개의 데이터가 들어갈 수 있는 균형 잡힌 트리 구조입니다.
+    -   모든 노드(루트, 브랜치, 리프)에 `Key`와 `Data`를 함께 저장합니다. `Data`는 실제 데이터의 주소값(포인터)입니다.
+
+*   **B+Tree:**
+    -   B-Tree를 개선한 자료구조입니다.
+    -   **리프 노드(Leaf Node)에만 `Key`와 `Data`를 저장**하고, 나머지 브랜치 노드에는 자식 노드를 찾아가기 위한 `Key`만 저장합니다.
+    -   모든 리프 노드는 **연결 리스트(Linked List)** 형태로 서로 연결되어 있어, 범위 검색(Range Scan) 시 매우 효율적입니다.
+
+**B-Tree 대비 B+Tree의 장점:**
+
+1.  **향상된 범위 검색 성능:** 리프 노드들이 연결 리스트로 이어져 있어, 특정 범위의 데이터를 조회할 때 트리를 다시 탐색할 필요 없이 리프 노드의 연결 리스트를 순차적으로 따라가기만 하면 됩니다. (예: `WHERE age BETWEEN 20 AND 30`)
+2.  **더 많은 키 저장 가능:** 브랜치 노드에 데이터 포인터를 저장하지 않으므로, 같은 크기의 노드에 더 많은 키를 저장할 수 있습니다. 이는 트리의 높이(height)를 낮추는 효과를 가져와, 결과적으로 디스크 I/O 횟수를 줄여 검색 성능을 향상시킵니다.
+    </details>
+    <details>
+    <summary><h4>꼬리질문 2: 클러스터형 인덱스(Clustered Index)와 비클러스터형 인덱스(Non-Clustered Index)의 차이는 무엇인가요?</h4></summary>
+    1.  **클러스터형 인덱스 (Clustered Index):**
+    -   **물리적 정렬:** 테이블의 데이터 자체가 인덱스의 키 값 순서대로 **물리적으로 정렬**되어 저장됩니다. 영어 사전을 생각하면 쉽습니다. (단어 순서대로 내용이 정렬됨)
+    -   **테이블당 하나만 존재:** 물리적인 순서는 하나만 가능하므로, 테이블당 하나의 클러스터형 인덱스만 생성할 수 있습니다.
+    -   **PK 제약조건:** Primary Key로 지정하면 해당 컬럼이 기본적으로 클러스터형 인덱스가 됩니다.
+    -   **리프 노드:** 리프 노드가 곧 데이터 자체입니다.
+    -   **장점:** 키 값 기반의 범위 검색 성능이 매우 뛰어납니다.
+    -   **단점:** 데이터 입력/수정 시 물리적인 재정렬이 필요할 수 있어 쓰기 성능이 비클러스터형보다 불리할 수 있습니다.
+
+2.  **비클러스터형 인덱스 (Non-Clustered Index / Secondary Index):**
+    -   **별도의 인덱스 페이지:** 데이터는 물리적으로 정렬되지 않고, 인덱스 키 값만 정렬된 별도의 인덱스 페이지를 가집니다. 일반적인 책의 '찾아보기'와 같습니다.
+    -   **테이블당 여러 개 존재:** 여러 개의 비클러스터형 인덱스를 생성할 수 있습니다.
+    -   **리프 노드:** 리프 노드는 실제 데이터의 위치를 가리키는 포인터(클러스터형 인덱스의 키 값 또는 물리적 주소)를 가집니다.
+    -   **장점:** 쓰기 성능이 클러스터형보다 유리합니다.
+    -   **단점:** 데이터를 찾기 위해 인덱스 페이지를 먼저 탐색한 후, 다시 데이터 페이지로 이동해야 하므로 한번의 디스크 I/O가 더 발생할 수 있습니다.
+    </details>
+    <details>
+    <summary><h4>꼬리질문 3: 실행 계획(Execution Plan)이 무엇인지 설명하고, 쿼리 성능을 최적화하기 위해 실행 계획을 어떻게 활용할 수 있을까요?</h4></summary>
+    **실행 계획** 은 데이터베이스 옵티마이저(Optimizer)가 사용자의 SQL 쿼리를 가장 효율적으로 실행하기 위해 수립한 **절차와 방법**입니다. `EXPLAIN` 키워드를 쿼리 앞에 붙여 확인할 수 있습니다.
+
+실행 계획에는 다음과 같은 정보가 포함됩니다.
+*   어떤 순서로 테이블에 접근할 것인가? (Join 순서)
+*   각 테이블에 접근할 때 어떤 인덱스를 사용할 것인가? (Full Scan vs Index Scan)
+*   어떤 조인 방식을 사용할 것인가? (Nested Loop Join, Hash Join 등)
+
+**실행 계획 활용법 (쿼리 튜닝):**
+
+1.  **Full Table Scan 확인:** `type` 컬럼이 `ALL`로 표시되면 테이블 전체를 스캔하고 있다는 의미이므로, 가장 먼저 확인해야 할 비효율 지점입니다. `WHERE` 절에 사용된 컬럼에 적절한 인덱스를 생성하여 `ref`, `range`, `index` 등으로 개선해야 합니다.
+
+2.  **불필요한 인덱스 사용 확인:** `possible_keys`에는 사용할 수 있는 인덱스 목록이, `key`에는 옵티마이저가 실제로 선택한 인덱스가 표시됩니다. 만약 옵티마이저가 최적의 인덱스를 선택하지 못했다면, 인덱스 힌트(`USE INDEX`)를 사용하거나 쿼리 구조를 변경하여 유도할 수 있습니다.
+
+3.  **조인 순서 및 방식 확인:** 조인 순서에 따라 성능이 크게 달라질 수 있습니다. 데이터가 적은 테이블을 먼저 읽는 것이 일반적으로 유리합니다.
+
+4.  **`Extra` 컬럼 확인:** `Using filesort`, `Using temporary`와 같은 문구가 나타나면 주의해야 합니다.
+    -   `Using filesort`: 인덱스를 사용하지 못하고 별도의 정렬 작업을 수행했다는 의미입니다. `ORDER BY` 절에 사용된 컬럼에 인덱스를 추가하는 것을 고려해야 합니다.
+    -   `Using temporary`: 임시 테이블을 생성했다는 의미로, 성능 저하의 주된 원인입니다. 쿼리 로직 자체를 재검토해야 할 수 있습니다.
+
+실행 계획을 분석하여 옵티마이저가 비효율적으로 동작하는 원인을 파악하고, 인덱스 추가/수정, 쿼리 재작성 등을 통해 최적의 실행 계획이 수립되도록 유도하는 것이 쿼리 튜닝의 핵심입니다.
+    </details>
+</details>
+<details>