post pending

Author: EeeasyCode

post-pending/clustered-index/index.md

@@ -0,0 +1,65 @@
+---
+title: "동시성 이슈 해결해보기"
+description: "동시에 같은 DB Table row 를 업데이트 하는 상황에는 어떻게 해결해야 할까?"
+date: 2025-05-14
+update: 2025-05-14
+tags:
+  - database
+series: "database"
+---
+
+# Clustered Index vs Non-Clustered Index
+
+데이터베이스에서 성능 최적화와 효율적인 데이터 검색은 매우 중요한 과제입니다. 이와 관련하여 인덱스는 데이터베이스의 핵심 요소 중 하나로, 데이터 정렬과 검색 속도를 크게 향상시킵니다. MySQL(InnoDB) 기준으로 Clustered Index와 Non-Clustered Index의 차이점과 사용 목적을 자세히 정리해보겠습니다.
+
+## Clustered Index란?
+
+Clustered Index는 테이블의 데이터 전체가 인덱스와 함께 물리적으로 정렬되는 방식의 인덱스입니다. 즉, 데이터 자체가 인덱스의 일부로 동작하기 때문에 데이터 검색에서 매우 효율적입니다. Clustered Index는 다음과 같은 특징을 가지고 있습니다:
+
+1. **테이블 당 하나만 생성 가능**: 물리적으로 데이터를 정렬해야 하므로 한 테이블에 여러 개의 Clustered Index를 생성할 수 없습니다.
+2. **기본 키(PK)와 연관**: 기본적으로 테이블의 기본 키(PK)가 Clustered Index로 설정됩니다. 만약 기본 키가 없을 경우, `unique`와 `NOT NULL` 조건을 만족하는 열이 사용됩니다. 이러한 조건이 없는 경우, MySQL은 내부적으로 `row_id`를 생성하여 Clustered Index를 설정합니다.
+3. **빠른 데이터 검색**: 데이터가 물리적으로 정렬되어 있으므로, 범위 검색(range query)이나 순차 검색(sequential scan)에서 매우 효율적입니다.
+
+### Clustered Index의 장점
+
+- 데이터와 인덱스가 동일한 구조를 가지므로 검색 속도가 빠릅니다.
+- 범위 검색이 자주 필요한 경우 특히 유리합니다.
+
+### Clustered Index의 단점
+
+- 데이터 삽입/삭제 시 물리적 정렬이 필요하므로 성능 저하가 발생할 수 있습니다.
+- 테이블 당 하나만 생성 가능하므로, 인덱스 설계에 제약이 따릅니다.
+
+## Non-Clustered Index란?
+
+Non-Clustered Index는 Clustered Index와 달리, 데이터 자체와는 별도로 생성되는 보조 인덱스입니다. Non-Clustered Index는 데이터가 물리적으로 정렬되지 않으며, 대신 정렬된 별도의 인덱스 페이지를 생성하여 관리합니다. 이로 인해 Non-Clustered Index는 다음과 같은 특징을 가집니다:
+
+1. **테이블 당 여러 개 생성 가능**: Clustered Index와 달리, Non-Clustered Index는 한 테이블에서 여러 개를 생성할 수 있습니다.
+2. **보조 인덱스**: Non-Clustered Index는 데이터의 실제 저장 위치를 참조(pointer)하며, 데이터 자체를 포함하지 않습니다.
+3. **데이터 정렬 없음**: 물리적으로 데이터를 정렬하지 않으므로 삽입/삭제 작업에서 성능 저하가 적습니다.
+
+### Non-Clustered Index의 장점
+
+- 하나의 테이블에 여러 개의 인덱스를 생성할 수 있어 다양한 검색 조건에서 유연하게 사용할 수 있습니다.
+- 삽입/삭제 작업에서 성능 저하가 적습니다.
+
+### Non-Clustered Index의 단점
+
+- 데이터 검색 시, 인덱스에서 데이터를 다시 참조해야 하므로 Clustered Index에 비해 검색 성능이 느릴 수 있습니다.
+- 추가적인 저장 공간이 필요합니다.
+
+## Clustered Index와 Non-Clustered Index의 비교
+
+| 특징             | Clustered Index                        | Non-Clustered Index                      |
+| ---------------- | -------------------------------------- | ---------------------------------------- |
+| 데이터 정렬 여부 | 물리적으로 데이터 정렬                 | 데이터 정렬 없음                         |
+| 생성 가능 개수   | 테이블 당 하나                         | 테이블 당 여러 개                        |
+| 저장 공간        | 추가 공간 불필요                       | 추가 저장 공간 필요                      |
+| 검색 성능        | 데이터와 인덱스가 동일하여 빠름        | 인덱스에서 데이터 참조로 인해 다소 느림  |
+| 삽입/삭제 성능   | 물리적 정렬 필요로 인해 성능 저하 가능 | 물리적 정렬 없음으로 인해 성능 저하 적음 |
+
+## 결론
+
+Clustered Index와 Non-Clustered Index는 각각의 장단점과 목적에 따라 사용됩니다. Clustered Index는 데이터가 자주 정렬되거나 범위 검색이 필요한 경우 유리하며, Non-Clustered Index는 다양한 검색 조건에 대응하기 위해 보조 인덱스로 활용됩니다. 데이터베이스 인덱스를 설계할 때, 테이블 구조와 쿼리 패턴을 고려하여 적절히 선택하는 것이 중요합니다.
+
+데이터베이스 성능을 최적화하기 위해 두 인덱스의 차이점을 명확히 이해하고, 적절한 전략을 수립하는 것이 필요합니다. 이를 통해 효율적인 데이터 관리와 검색 성능 향상을 도모할 수 있습니다.

post-pending/clustered-index/mysql-index-comparison.md

@@ -0,0 +1,114 @@
+---
+title: "Clustered vs Non-Clustered 차이와 선택 기준"
+description: "MySQL에서 인덱스 설계를 제대로 이해해보자"
+date: 2025-06-22
+tags: [mysql, index, database]
+series: "database"
+---
+
+느려터진 쿼리, 도대체 왜일까요?
+
+많은 경우, 적절하지 않은 인덱스 구조가 원인입니다.  
+특히 InnoDB를 사용하는 MySQL에서는 **Clustered Index와 Non-Clustered Index**의 차이를 제대로 이해하지 않으면, 성능을 개선하기 어렵습니다.
+
+이번 글에서는 두 인덱스의 구조적 차이, 장단점, 그리고 실제 쿼리 설계 시 어떤 기준으로 선택해야 하는지를 정리해보겠습니다.
+
+---
+
+## Clustered Index란?
+
+Clustered Index는 **데이터가 인덱스 자체에 포함되어 물리적으로 정렬**되는 방식입니다.  
+InnoDB에서는 테이블당 하나만 가질 수 있으며, 보통 **기본 키(PK)** 가 해당 역할을 합니다.
+
+### 특징
+
+- **하나만 생성 가능**: 데이터 자체가 인덱스의 일부이기 때문에 테이블당 1개만 설정 가능
+- **데이터 정렬 포함**: 인덱스의 순서 = 데이터 정렬 순서
+- **빠른 범위 쿼리**에 유리: 연속된 값을 조회하는 쿼리에 매우 빠름
+
+### 예시
+
+```sql
+CREATE TABLE user (
+  id BIGINT PRIMARY KEY, -- id가 자동으로 Clustered Index가 됨
+  name VARCHAR(100),
+  created_at DATETIME
+);
+```
+
+이 경우, `id` 기준으로 데이터가 디스크에 정렬되어 저장됩니다.
+
+---
+
+## Non-Clustered Index란?
+
+Non-Clustered Index는 **인덱스와 데이터가 분리되어 저장**됩니다.  
+보조 인덱스로서 사용되며, **데이터 위치를 가리키는 포인터를 포함**합니다.
+
+### 특징
+
+- **여러 개 생성 가능**: 다양한 쿼리 조건에 맞게 인덱스 생성 가능
+- **데이터 참조 필요**: 인덱스만으로 값을 조회할 수 없으면 테이블을 한 번 더 읽어야 함
+- **정렬 없음**: 물리적 정렬이 없으므로 삽입/삭제가 빠름
+
+### 예시
+
+```sql
+CREATE INDEX idx_user_name ON user(name);
+```
+
+이 인덱스는 `name`을 기준으로 정렬된 인덱스 트리를 만들지만, 실제 데이터는 Clustered Index에 위치해 있으므로 **데이터를 추가로 참조해야** 합니다.
+
+---
+
+## EXPLAIN으로 보는 차이
+
+아래 쿼리를 `EXPLAIN`으로 실행해보면 차이를 확인할 수 있습니다:
+
+```sql
+-- Clustered Index를 사용하는 쿼리
+SELECT * FROM user WHERE id BETWEEN 1 AND 100;
+
+-- Non-Clustered Index를 사용하는 쿼리
+SELECT * FROM user WHERE name = 'Alice';
+```
+
+- 첫 번째 쿼리는 데이터 자체가 `id`로 정렬되어 있어 빠른 접근이 가능합니다.
+- 두 번째 쿼리는 `name` 인덱스를 따라가서 `id`를 찾아야 하므로, **인덱스 → 테이블** 두 번 접근합니다.
+
+---
+
+## 비교표: Clustered vs Non-Clustered
+
+| 항목           | Clustered Index                 | Non-Clustered Index                 |
+| -------------- | ------------------------------- | ----------------------------------- |
+| 정렬 방식      | 데이터가 인덱스 기준으로 정렬됨 | 정렬된 인덱스 구조, 데이터는 별도   |
+| 생성 가능 개수 | 1개만 생성 가능                 | 여러 개 생성 가능                   |
+| 저장 공간      | 추가 공간 거의 없음             | 인덱스 공간 외에도 데이터 참조 필요 |
+| 조회 속도      | 빠름 (범위 조회에 특히 유리)    | 조건에 따라 느릴 수 있음            |
+| 삽입/삭제 성능 | 느릴 수 있음 (정렬 유지 필요)   | 빠름 (정렬 없음)                    |
+
+---
+
+## 언제 어떤 인덱스를 써야 할까?
+
+- **Clustered Index 추천**
+
+  - PK 기반으로 데이터 조회가 대부분일 때
+  - 범위 쿼리(`BETWEEN`, `ORDER BY`)가 자주 사용될 때
+  - 정렬된 데이터 저장이 이점이 될 때
+
+- **Non-Clustered Index 추천**
+  - 다양한 검색 조건을 대응해야 할 때
+  - 여러 필드에 대해 인덱스를 걸어야 할 때
+  - 삽입/삭제가 자주 일어나는 테이블일 때
+
+---
+
+## 결론
+
+Clustered Index와 Non-Clustered Index는 단순히 "있으면 좋은" 것이 아니라, **성능에 직결되는 중요한 설계 요소**입니다.
+
+쿼리 성능이 고민이라면, 지금 사용하는 인덱스 구조가 쿼리 목적에 맞는지 꼭 점검해보세요.
+
+> 여러분은 어떤 기준으로 인덱스를 설계하시나요?