클러스터형 인덱스 — PK가 데이터 정렬을 결정하는 이유

클러스터형 인덱스: 인덱스 = 데이터 (리프 노드에 행 데이터 전체)
세컨더리 인덱스:  인덱스 → PK 값 (리프 노드에 PK 값만)

┌─────────── B+Tree 구조 ───────────┐
│           [루트 노드]               │
│          /    |    \               │
│    [내부 노드] [내부 노드] ...       │
│     /  \      /  \                │
│  [리프]  [리프]  [리프]  [리프]     │
│  ┌───┐  ┌───┐  ┌───┐  ┌───┐     │
│  │실제│  │실제│  │실제│  │실제│     │
│  │데이│  │데이│  │데이│  │데이│     │
│  │터  │  │터  │  │터  │  │터  │     │
│  └───┘  └───┘  └───┘  └───┘     │
│  PK순으로 연결 (양방향 링크드 리스트)  │
└───────────────────────────────────┘

SELECT * FROM users WHERE id = 42;

루트 노드: id=42가 어느 범위인지 확인
  → 내부 노드: 해당 범위의 페이지로 이동
    → 리프 노드: id=42의 행 데이터를 바로 반환

SELECT * FROM users WHERE id BETWEEN 100 AND 200;

CREATE INDEX idx_name ON users(name);

세컨더리 인덱스 (idx_name):
  리프 노드: name='김철수' → PK=42

클러스터형 인덱스:
  PK=42 → {id:42, name:'김철수', age:28, email:'...'}

SELECT * FROM users WHERE name = '김철수';

1단계: idx_name에서 name='김철수' 검색 → PK=42 획득
2단계: 클러스터형 인덱스에서 PK=42로 검색 → 행 데이터 반환

세컨더리 인덱스 리프: [인덱스 컬럼 값] + [PK 값]

INT PK (4바이트):     세컨더리 인덱스 리프 = name + 4바이트
BIGINT PK (8바이트):  세컨더리 인덱스 리프 = name + 8바이트
UUID PK (36바이트):   세컨더리 인덱스 리프 = name + 36바이트

CREATE TABLE users (
    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(50)
);

CREATE TABLE users (
    id CHAR(36) PRIMARY KEY,  -- 'a1b2c3d4-e5f6-...'
    name VARCHAR(50)
);

AUTO_INCREMENT (순차 삽입):
[1,2,3,4,5] → [1,2,3,4,5][6,7,8,9,10] → 끝에만 추가, 분할 최소

UUID (랜덤 삽입):
[a,c,f,h,k] → 'b' 삽입 → [a,b,c] [f,h,k] → 기존 페이지를 분할!
              데이터 이동 + 상위 노드 업데이트 + 공간 낭비

-- 방법 1: UUID v7 (시간 기반 정렬 가능, 2024년 표준화)
-- 앞부분이 타임스탬프이므로 대체로 순차적

-- 방법 2: BINARY(16)으로 저장하여 크기 절약
CREATE TABLE users (
    id BINARY(16) PRIMARY KEY,
    name VARCHAR(50)
);

-- UUID 문자열 → BINARY 변환
INSERT INTO users VALUES (UUID_TO_BIN(UUID(), 1), '김철수');
-- UUID_TO_BIN의 두 번째 인자 1: 시간 부분을 앞으로 재배치 (순차성 향상)

SELECT BIN_TO_UUID(id, 1) AS id, name FROM users;

1순위: PRIMARY KEY로 지정된 컬럼
2순위: 첫 번째 UNIQUE NOT NULL 인덱스
3순위: InnoDB가 6바이트 내부 Row ID를 자동 생성

-- 복합 PK: (user_id, order_date) 순서로 물리적 정렬
CREATE TABLE user_orders (
    user_id INT NOT NULL,
    order_date DATE NOT NULL,
    amount DECIMAL(10,2),
    PRIMARY KEY (user_id, order_date)
);

-- 빠름: PK 선두 컬럼으로 검색
SELECT * FROM user_orders WHERE user_id = 1;

-- 빠름: PK 전체 컬럼으로 범위 검색
SELECT * FROM user_orders WHERE user_id = 1 AND order_date >= '2026-01-01';

-- 느림: PK 두 번째 컬럼만으로 검색 (최좌선 접두사 미충족)
SELECT * FROM user_orders WHERE order_date >= '2026-01-01';

-- 테이블 단편화 확인
SELECT TABLE_NAME, DATA_LENGTH, DATA_FREE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'my_db' AND TABLE_NAME = 'users';

-- DATA_FREE가 크면 단편화가 심한 것

-- 단편화 해소 (테이블 재구성)
ALTER TABLE users ENGINE=InnoDB;
-- 또는
OPTIMIZE TABLE users;