EXPLAIN
SELECT id, created_at
FROM orders
WHERE user_id = 10 AND created_at >= '2025-01-01'
ORDER BY created_at DESC
LIMIT 20;

-- 인덱스를 못 타기 쉬움(컬럼에 함수)
WHERE DATE(created_at) = '2025-12-16'

-- 범위로 바꾸면 인덱스를 타기 쉬움
WHERE created_at >= '2025-12-16 00:00:00'
  AND created_at <  '2025-12-17 00:00:00'

graph TD
    subgraph Clustered_Index ["Clustered Index (PK)"]
        Root1[Root] --> Leaf1[Leaf Node]
        Leaf1 --> Data1["📄 실제 데이터 행 (Row Data)"]
    end
    
    subgraph Non_Clustered_Index ["Non-Clustered Index"]
        Root2[Root] --> Leaf2[Leaf Node]
        Leaf2 --> Pointer2["📍 PK 값 (Pointer)"]
    end
    
    Pointer2 -.->|Lookup| Root1
    
    style Data1 fill:#ffccbc,stroke:#d84315
    style Pointer2 fill:#b3e5fc,stroke:#0277bd

graph TD
    Root[Root Node] --> Branch1[Branch: 1-50]
    Root --> Branch2[Branch: 51-100]
    
    Branch1 --> Leaf1[Leaf: 10, 20]
    Branch1 --> Leaf2[Leaf: 30, 40]
    
    Branch2 --> Leaf3[Leaf: 60, 70]
    Branch2 --> Leaf4[Leaf: 80, 90]
    
    Leaf1 -.->|Linked List| Leaf2
    Leaf2 -.->|Linked List| Leaf3
    Leaf3 -.->|Linked List| Leaf4
    
    style Root fill:#e3f2fd,stroke:#2196f3
    style Branch1 fill:#fff9c4,stroke:#fbc02d
    style Leaf1 fill:#c8e6c9,stroke:#4caf50

classDiagram
    class CompositeIndex {
        +Male (남)
        +Female (여)
    }
    class MaleGroup {
        20세
        21세
        25세
    }
    class FemaleGroup {
        20세
        22세
        30세
    }
    
    CompositeIndex *-- MaleGroup : 1차 정렬 (성별)
    CompositeIndex *-- FemaleGroup
    MaleGroup : 2차 정렬 (나이)

(남, 20), (남, 21), (남, 25) ... (여, 20), (여, 22) ...

-- ✅ 인덱스 잘 탐 (성별로 먼저 거르고 나이 찾음)
SELECT * FROM users WHERE gender = '남' AND age = 20;

-- ❌ 인덱스 못 탐 (성별 없이 나이만? 정렬 안 되어 있음)
SELECT * FROM users WHERE age = 20;

sequenceDiagram
    participant Query
    participant Index
    participant Table
    
    Note over Query: SELECT name FROM users <br/> WHERE id = 10
    
    Query->>Index: "id=10 있니?"
    Note right of Index: 어, 나 name도 갖고 있는데?
    Index-->>Query: 여기 있어! (name='Alice')
    
    Note over Table: (테이블 접근 안 함 ⚡)

인덱스: users(age)

                    [50]                     ← Root
                   /    \
                 /        \
            [20, 35]      [65, 80]           ← Branch
            /  |  \        /  |  \
          /    |    \    /    |    \
      [10]  [25]  [40] [55] [70]  [90]      ← Leaf (실제 데이터 포인터)
       ↓     ↓     ↓    ↓    ↓     ↓
     Row1  Row2  Row3 Row4 Row5  Row6

-- 1. Root Node: 25 < 50 → 왼쪽 Branch
-- 2. Branch Node: 20 ≤ 25 < 35 → 중간 Leaf
-- 3. Leaf Node: 25 발견 → Row 포인터 반환

SELECT * FROM users WHERE age = 25;
-- → 3번의 블록 I/O (Root → Branch → Leaf)

-- 테이블: users (100만 건)
-- 블록 크기: 8KB, Row 크기: 200 bytes
-- 한 블록당 40개 Row

-- ❌ Full Table Scan
SELECT * FROM users WHERE age = 25;
-- → 25,000 블록 읽기 (100만 / 40)
-- → 약 200MB I/O

-- ✅ Index Scan (B-Tree depth = 3)
CREATE INDEX idx_age ON users(age);
SELECT * FROM users WHERE age = 25;
-- → 3 블록 읽기 (Root + Branch + Leaf)
-- → 해당 Row 블록 1개 추가
-- → 총 4 블록 (약 32KB I/O)
-- → 6,250배 빠름!

-- ✅ B-Tree 인덱스가 유리
SELECT * FROM users WHERE age BETWEEN 20 AND 30;  -- 범위 검색
SELECT * FROM users WHERE name LIKE 'John%';       -- Prefix 검색
SELECT * FROM users ORDER BY created_at DESC;     -- 정렬

-- ✅ Hash 인덱스가 유리
SELECT * FROM users WHERE user_id = 12345;        -- 등호 검색 (PK)
SELECT * FROM cache WHERE cache_key = 'key123';   -- 정확한 매칭

-- MySQL InnoDB 예시

-- Clustered Index (PK)
CREATE TABLE users (
    id INT PRIMARY KEY,      -- Clustered Index
    name VARCHAR(100),
    age INT
);
-- → 실제 데이터가 id 순서로 디스크에 저장됨

-- Non-Clustered Index (Secondary Index)
CREATE INDEX idx_age ON users(age);
-- → age 인덱스 별도 저장
-- → Leaf Node는 PK(id) 값을 가짐
-- → age 인덱스 조회 → PK로 다시 Clustered Index 조회 (2단계)

-- ✅ Clustered Index (빠름)
SELECT * FROM users WHERE id = 100;
-- → 1번 조회 (Clustered Index)

-- ⚠️ Non-Clustered Index (느림)
SELECT * FROM users WHERE age = 25;
-- → 1번: age 인덱스 조회 (id = 100 발견)
-- → 2번: Clustered Index에서 id = 100 조회
-- → 총 2번 조회

-- 테이블: orders
-- 데이터: 100만 건
-- country: 10개 (선택도 낮음)
-- status: 5개 (선택도 낮음)
-- created_at: 백만 개 (선택도 높음)

-- ❌ 잘못된 순서
CREATE INDEX idx_bad ON orders(country, status, created_at);

SELECT * FROM orders
WHERE status = 'COMPLETED'
  AND created_at >= '2025-01-01';
-- → country 조건이 없어서 인덱스 사용 불가! ❌

-- ✅ 올바른 순서 (선택도 높은 컬럼 우선)
CREATE INDEX idx_good ON orders(status, country, created_at);

SELECT * FROM orders
WHERE status = 'COMPLETED'
  AND created_at >= '2025-01-01';
-- → status로 인덱스 시작 가능 ✅
-- → created_at으로 범위 검색 ✅

CREATE INDEX idx_abc ON users(a, b, c);

-- ✅ 인덱스 사용 가능
WHERE a = 1
WHERE a = 1 AND b = 2
WHERE a = 1 AND b = 2 AND c = 3
WHERE a = 1 AND c = 3  -- a만 사용

-- ❌ 인덱스 사용 불가
WHERE b = 2
WHERE c = 3
WHERE b = 2 AND c = 3

-- 사용자 검색 쿼리 패턴 분석
-- 패턴 1: WHERE city = 'Seoul' AND age = 25 (70%)
-- 패턴 2: WHERE city = 'Seoul' AND gender = 'M' (20%)
-- 패턴 3: WHERE city = 'Seoul' (10%)

-- ✅ 최적 인덱스 설계
CREATE INDEX idx_city_age_gender ON users(city, age, gender);

-- 패턴 1 (70%)
SELECT * FROM users WHERE city = 'Seoul' AND age = 25;
-- → idx_city_age_gender 사용 (city, age) ✅

-- 패턴 2 (20%)
SELECT * FROM users WHERE city = 'Seoul' AND gender = 'M';
-- → idx_city_age_gender 사용 (city만) ⚠️
-- → gender는 Skip Scan

-- 패턴 3 (10%)
SELECT * FROM users WHERE city = 'Seoul';
-- → idx_city_age_gender 사용 (city) ✅

-- ❌ 범위 검색을 앞에 배치
CREATE INDEX idx_bad ON orders(created_at, status);

SELECT * FROM orders
WHERE created_at >= '2025-01-01'
  AND status = 'COMPLETED';
-- → created_at 범위 검색 후 status 조건은 인덱스 미사용 ⚠️

-- ✅ 등호 검색을 앞에 배치
CREATE INDEX idx_good ON orders(status, created_at);

SELECT * FROM orders
WHERE status = 'COMPLETED'
  AND created_at >= '2025-01-01';
-- → status 등호 검색 → created_at 범위 검색 ✅
-- → 인덱스 완전 활용

-- 테이블: users (10개 인덱스)
INSERT INTO users VALUES (...);

-- 실행 내용:
-- 1. 실제 데이터 삽입
-- 2. 인덱스 1 업데이트
-- 3. 인덱스 2 업데이트
-- ...
-- 11. 인덱스 10 업데이트
-- → 총 11번 쓰기 작업! ⚠️

-- 성능 영향:
-- 인덱스 0개: 100,000 INSERTs/sec
-- 인덱스 5개: 50,000 INSERTs/sec (50% 감소)
-- 인덱스 10개: 20,000 INSERTs/sec (80% 감소)

CREATE INDEX idx_gender_age ON users(gender, age);

-- ❌ 일반적으로는 인덱스 사용 불가
SELECT * FROM users WHERE age = 25;
-- (gender 조건 없음)

-- ✅ Skip Scan 사용 (Oracle, PostgreSQL 11+)
-- 내부적으로:
SELECT * FROM users WHERE gender = 'M' AND age = 25
UNION ALL
SELECT * FROM users WHERE gender = 'F' AND age = 25;
-- → gender 값(M, F)을 자동으로 반복하며 검색

-- 테이블: users (100만 건)
CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100),
    age INT,
    city VARCHAR(50)
);

-- ❌ Non-Covering Index
CREATE INDEX idx_age ON users(age);

SELECT id, name, email FROM users WHERE age = 25;

-- 실행 과정:
-- 1. idx_age에서 age = 25인 Row 검색
-- 2. Leaf Node에서 PK(id) 값 획득
-- 3. Clustered Index에서 id로 실제 Row 조회 (name, email 가져옴)
-- → 2번 조회 (Index + Table) ⚠️

-- ✅ Covering Index
CREATE INDEX idx_age_id_name_email ON users(age, id, name, email);

SELECT id, name, email FROM users WHERE age = 25;

-- 실행 과정:
-- 1. idx_age_id_name_email에서 age = 25인 Row 검색
-- 2. 인덱스 Leaf Node에 id, name, email이 모두 있음!
-- → 1번 조회 (Index만) ✅
-- → 테이블 접근 불필요 (빠름!)

-- 실험: 100만 건 테이블, age = 25 (5만 건)

-- ❌ Non-Covering Index
CREATE INDEX idx_age ON users(age);
SELECT id, name, email FROM users WHERE age = 25;
-- → 실행 시간: 500ms
-- → 블록 I/O: 50,000 (인덱스 + 테이블)

-- ✅ Covering Index
CREATE INDEX idx_age_covering ON users(age, id, name, email);
SELECT id, name, email FROM users WHERE age = 25;
-- → 실행 시간: 50ms (10배 빠름!)
-- → 블록 I/O: 5,000 (인덱스만)

-- 빈번한 쿼리 패턴
SELECT user_id, name, email
FROM users
WHERE status = 'ACTIVE'
  AND created_at >= '2025-01-01'
ORDER BY created_at DESC
LIMIT 10;

-- ✅ Covering Index 설계
CREATE INDEX idx_covering ON users(
    status,          -- WHERE 조건
    created_at,      -- WHERE 조건 + ORDER BY
    user_id,         -- SELECT 컬럼
    name,            -- SELECT 컬럼
    email            -- SELECT 컬럼
);

-- → 인덱스만으로 모든 데이터 반환 ✅

-- ❌ 과도한 Covering Index
CREATE INDEX idx_too_large ON users(
    age,
    name,       -- VARCHAR(100)
    email,      -- VARCHAR(100)
    address,    -- VARCHAR(200)
    description -- TEXT
);
-- → 인덱스 크기가 테이블보다 클 수 있음! ⚠️
-- → 인덱스 캐시 효율 저하

UPDATE users SET email = 'new@example.com' WHERE id = 123;

-- Non-Covering Index:
-- → users 테이블 업데이트
-- → idx_age 인덱스는 email 없으므로 업데이트 불필요

-- Covering Index:
-- → users 테이블 업데이트
-- → idx_covering 인덱스도 email 컬럼 업데이트 필요 ⚠️

-- ✅ INCLUDE 사용 (PostgreSQL)
CREATE INDEX idx_users_include ON users(age, status)
INCLUDE (name, email);

-- 동작:
-- Branch Node: age, status만 저장 (정렬 키)
-- Leaf Node: age, status, name, email 모두 저장

-- 장점:
-- 1. Branch Node 크기 감소 → 메모리 효율 향상
-- 2. Covering Index 효과 유지
-- 3. 인덱스 크기 20-40% 감소

-- 일반 복합 인덱스
CREATE INDEX idx_normal ON users(age, status, name, email);
-- → Branch/Leaf 모두 4개 컬럼 저장
-- → 인덱스 크기: 500MB

-- INCLUDE 사용
CREATE INDEX idx_include ON users(age, status) INCLUDE (name, email);
-- → Branch: 2개 컬럼
-- → Leaf: 4개 컬럼
-- → 인덱스 크기: 350MB (30% 감소)

Selectivity = Distinct 값 개수 / 전체 Row 개수

높은 선택도: 1에 가까움 (좋음)
낮은 선택도: 0에 가까움 (나쁨)

-- 테이블: users (100만 건)

-- ✅ 높은 선택도 (인덱스 효과적)
-- user_id (Primary Key)
SELECT COUNT(DISTINCT user_id) FROM users;  -- 100만 개
-- Selectivity = 1,000,000 / 1,000,000 = 1.0 (완벽!)

-- email (Unique)
SELECT COUNT(DISTINCT email) FROM users;  -- 100만 개
-- Selectivity = 1,000,000 / 1,000,000 = 1.0 (완벽!)

-- ⚠️ 중간 선택도 (상황에 따라)
-- city (도시)
SELECT COUNT(DISTINCT city) FROM users;  -- 100개
-- Selectivity = 100 / 1,000,000 = 0.0001 (낮음)

-- ❌ 낮은 선택도 (인덱스 비효율적)
-- gender (성별)
SELECT COUNT(DISTINCT gender) FROM users;  -- 2개 (M, F)
-- Selectivity = 2 / 1,000,000 = 0.000002 (매우 낮음)

-- is_active (활성 여부)
SELECT COUNT(DISTINCT is_active) FROM users;  -- 2개 (true, false)
-- Selectivity = 2 / 1,000,000 = 0.000002 (매우 낮음)

-- ❌ 낮은 선택도 (인덱스 비효율)
CREATE INDEX idx_gender ON users(gender);

SELECT * FROM users WHERE gender = 'M';
-- → 50만 건 반환 (전체의 50%)
-- → Full Table Scan이 더 빠를 수 있음! ⚠️

-- 이유:
-- 1. 인덱스 조회: 50만 번
-- 2. 테이블 조회: 50만 번
-- 3. Random I/O: 50만 번
-- → Full Table Scan: 순차 I/O 25,000번이 더 빠름!

-- ✅ 높은 선택도 (인덱스 효과적)
CREATE INDEX idx_email ON users(email);

SELECT * FROM users WHERE email = 'john@example.com';
-- → 1건 반환 (0.0001%)
-- → Index Scan이 훨씬 빠름! ✅

-- ❌ 단일 컬럼 (낮은 선택도)
CREATE INDEX idx_status ON orders(status);
-- status: 'PENDING', 'COMPLETED', 'CANCELLED' (3개 값)
-- Selectivity = 3 / 1,000,000 = 0.000003

-- ✅ 복합 인덱스 (높은 선택도)
CREATE INDEX idx_status_date ON orders(status, created_at);
-- (status, created_at) 조합: 거의 유니크
-- Selectivity ≈ 0.9 (높음!)

SELECT * FROM orders
WHERE status = 'PENDING'
  AND created_at >= '2025-01-01';
-- → 복합 인덱스로 선택도 크게 향상 ✅

-- ❌ 전체 인덱스 (비효율)
CREATE INDEX idx_is_active ON users(is_active);
-- is_active: true (95%), false (5%)

SELECT * FROM users WHERE is_active = false;
-- → 5만 건 (5%)

-- ✅ Partial Index (PostgreSQL, SQLite)
CREATE INDEX idx_inactive_users ON users(user_id)
WHERE is_active = false;
-- → is_active = false인 Row만 인덱싱
-- → 인덱스 크기: 95% 감소
-- → 조회 속도: 동일하거나 더 빠름

SELECT * FROM users WHERE is_active = false;
-- → idx_inactive_users 사용 ✅

-- 1. 낮은 선택도 (결과가 전체의 20% 이상)
SELECT * FROM users WHERE gender = 'M';
-- → Full Table Scan 선택

-- 2. 함수 사용
CREATE INDEX idx_name ON users(name);
SELECT * FROM users WHERE UPPER(name) = 'JOHN';
-- → 인덱스 무효화 ❌

-- ✅ 함수 기반 인덱스 (Function-based Index)
CREATE INDEX idx_upper_name ON users(UPPER(name));
SELECT * FROM users WHERE UPPER(name) = 'JOHN';
-- → idx_upper_name 사용 ✅

-- 3. LIKE '%keyword' (prefix 아님)
CREATE INDEX idx_email ON users(email);
SELECT * FROM users WHERE email LIKE '%@gmail.com';
-- → 인덱스 무효화 ❌ (prefix가 아님)

SELECT * FROM users WHERE email LIKE 'john%';
-- → idx_email 사용 ✅ (prefix)

-- 4. OR 조건 (인덱스가 없는 컬럼)
SELECT * FROM users
WHERE user_id = 123  -- 인덱스 있음
   OR name = 'John'; -- 인덱스 없음
-- → Full Table Scan

-- 5. 데이터 타입 불일치
CREATE INDEX idx_user_id ON users(user_id);  -- INT
SELECT * FROM users WHERE user_id = '123';   -- STRING
-- → 암묵적 형변환으로 인덱스 무효화 ⚠️

-- 문제 쿼리
SELECT *
FROM users
WHERE city = 'Seoul'
  AND age BETWEEN 20 AND 30
  AND created_at >= '2024-01-01'
ORDER BY created_at DESC
LIMIT 10;

-- 실행 계획 확인
EXPLAIN ANALYZE
SELECT ...;

-- 출력:
-- Seq Scan on users  (cost=0..50000 rows=100000)
--   Filter: city = 'Seoul' AND age >= 20 AND age <= 30
-- → Full Table Scan! ⚠️
-- → 100만 건 스캔

-- ✅ Covering Index 생성
CREATE INDEX idx_city_age_created_covering ON users(
    city,          -- WHERE 조건 (선택도 중간)
    age,           -- WHERE 조건 (선택도 중간)
    created_at     -- WHERE + ORDER BY
) INCLUDE (
    user_id, name, email  -- SELECT 컬럼
);

-- 실행 계획 (개선 후)
EXPLAIN ANALYZE
SELECT ...;

-- 출력:
-- Index Only Scan using idx_city_age_created_covering
--   (cost=0..100 rows=10)
-- → 인덱스만 사용! ✅
-- → 1,000건만 스캔 (1,000배 감소)

-- 성능 결과:
-- 실행 시간: 30초 → 0.1초 (300배 개선)
-- CPU 사용률: 90% → 10%

-- 기존 인덱스
CREATE INDEX idx_old ON orders(created_at, status, user_id);

-- 쿼리 패턴 (80%)
SELECT * FROM orders
WHERE user_id = 12345
  AND status = 'PENDING';

-- 실행 계획:
-- Index Scan using idx_old  (cost=0..5000)
--   Filter: user_id = 12345 AND status = 'PENDING'
-- → created_at 조건이 없어 인덱스 효율 낮음 ⚠️

-- 컬럼별 선택도 분석
SELECT
    COUNT(DISTINCT created_at) / COUNT(*) AS created_selectivity,
    COUNT(DISTINCT status) / COUNT(*) AS status_selectivity,
    COUNT(DISTINCT user_id) / COUNT(*) AS user_selectivity
FROM orders;

-- 결과:
-- created_selectivity: 0.8 (높음)
-- status_selectivity: 0.000005 (매우 낮음, 5개 값)
-- user_selectivity: 0.1 (중간)

-- 쿼리 패턴 분석:
-- user_id 조건: 80%
-- status 조건: 90%
-- created_at 조건: 30%

-- ✅ 인덱스 순서 변경
DROP INDEX idx_old;
CREATE INDEX idx_new ON orders(user_id, status, created_at);

-- 이유:
-- 1. user_id: 쿼리에 80% 사용 → 첫 번째
-- 2. status: 쿼리에 90% 사용 → 두 번째
-- 3. created_at: 쿼리에 30% 사용 → 세 번째 (범위 검색)

-- 실행 계획 (개선 후):
-- Index Scan using idx_new  (cost=0..50)
--   Index Cond: user_id = 12345 AND status = 'PENDING'
-- → 효율적인 인덱스 사용! ✅

-- 성능 결과:
-- 실행 시간: 2초 → 0.2초 (10배 개선)
-- 스캔 Row: 10만 건 → 100건 (1,000배 감소)

-- 테이블에 인덱스 15개 존재!
SHOW INDEX FROM orders;

-- 출력:
-- idx_user_id
-- idx_status
-- idx_created_at
-- idx_user_status
-- idx_status_created
-- ... (총 15개)

INSERT INTO orders VALUES (...);
-- → 15개 인덱스 모두 업데이트 필요! ⚠️
-- → 실행 시간: 5초

-- 인덱스 사용 통계 확인 (PostgreSQL)
SELECT
    schemaname,
    tablename,
    indexname,
    idx_scan,  -- 인덱스 스캔 횟수
    idx_tup_read
FROM pg_stat_user_indexes
WHERE tablename = 'orders'
ORDER BY idx_scan ASC;

-- 결과:
-- idx_user_id: 1,000,000 (활발히 사용)
-- idx_status_created: 500,000 (활발히 사용)
-- idx_unused_1: 0 (미사용!) ⚠️
-- idx_unused_2: 10 (거의 미사용) ⚠️
-- ...

-- ✅ 미사용 인덱스 제거
DROP INDEX idx_unused_1;
DROP INDEX idx_unused_2;
DROP INDEX idx_unused_3;
-- ... (7개 제거)

-- ✅ 중복 인덱스 통합
-- 기존:
-- idx_user_id (user_id)
-- idx_user_status (user_id, status)
-- → idx_user_id는 불필요! (idx_user_status로 커버 가능)

DROP INDEX idx_user_id;

-- 최종: 15개 → 5개 인덱스만 유지

-- 성능 결과:
-- INSERT 시간: 5초 → 0.5초 (10배 개선)
-- DB Write 대기: 80% 감소

CREATE TABLE test_index (
    id INT AUTO_INCREMENT PRIMARY KEY,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP, -- B-Tree 테스트용
    category VARCHAR(50), -- Hash Index 테스트용  
    description TEXT, -- Fulltext Index 테스트용

    INDEX idx_btree_created_at (created_at),
    INDEX idx_hash_category USING HASH (category),
    FULLTEXT INDEX idx_fulltext_description (description)
);

INSERT INTO test_index (created_at, category, description)
SELECT
    NOW() - INTERVAL FLOOR(RAND() * 365) DAY,
    ELT(FLOOR(1 + (RAND() * 3)), 'A', 'B', 'C'),
    CONCAT(
        'This is a sample description ',
        FLOOR(RAND() * 1000),
        ' with random content'
    )
FROM information_schema.tables AS a
CROSS JOIN information_schema.tables AS b
LIMIT 100000;

EXPLAIN ANALYZE
SELECT * FROM test_index
WHERE created_at BETWEEN '2024-10-01' AND '2024-11-01';

-> Index range scan on test_index using idx_btree_created_at over ('2024-10-01 00:00:00' <= created_at <= '2024-11-01 00:00:00'), with index condition: (test_index.created_at between '2024-10-01' and '2024-11-01')  (cost=3824 rows=8498) (actual time=0.19..26.6 rows=8498 loops=1)

EXPLAIN ANALYZE
SELECT * FROM test_index
IGNORE INDEX(idx_btree_created_at)      -- B-Tree 인덱스 제거
WHERE created_at BETWEEN '2024-10-01' AND '2024-11-01';

-> Filter: (test_index.created_at between '2024-10-01' and '2024-11-01')  (cost=10102 rows=11054) (actual time=0.0711..66.4 rows=8498 loops=1)
    -> Table scan on test_index  (cost=10102 rows=99495) (actual time=0.0548..42.1 rows=100000 loops=1)

EXPLAIN ANALYZE 
SELECT * FROM test_index 
WHERE created_at='2025-01-01 06:53:52';

-> Index lookup on test_index using idx_btree_created_at (created_at=TIMESTAMP'2025-01-01 06:53:52')  (cost=101 rows=288) (actual time=0.0881..1.49 rows=288 loops=1)

EXPLAIN ANALYZE
SELECT * FROM test_index
IGNORE INDEX(idx_btree_created_at)      -- B-Tree 인덱스 제거
WHERE created_at='2025-01-01 06:53:52';

| -> Filter: (test_index.created_at = TIMESTAMP'2025-01-01 06:53:52')  (cost=10102 rows=270) (actual time=0.239..45.8 rows=288 loops=1)
    -> Table scan on test_index  (cost=10102 rows=99495) (actual time=0.03..39.5 rows=100000 loops=1)

EXPLAIN ANALYZE  
SELECT * FROM test_index 
WHERE category BETWEEN 'A' AND 'B';

-> Filter: (test_index.category between 'A' and 'B')  (cost=10102 rows=49747) (actual time=0.0455..53.5 rows=66775 loops=1)
    -> Table scan on test_index  (cost=10102 rows=99495) (actual time=0.0401..41 rows=100000 loops=1)

EXPLAIN ANALYZE  
SELECT * FROM test_index 
IGNORE INDEX(idx_hash_category)     -- Hash 인덱스 제거
WHERE category BETWEEN 'A' AND 'B';

| -> Filter: (test_index.category between 'A' and 'B')  (cost=10102 rows=11054) (actual time=0.0491..53.9 rows=66775 loops=1)
    -> Table scan on test_index  (cost=10102 rows=99495) (actual time=0.045..41.2 rows=100000 loops=1)

EXPLAIN ANALYZE  
SELECT * FROM test_index 
WHERE category='B';

-> Index lookup on test_index using idx_hash_category (category='B')  (cost=5431 rows=49747) (actual time=0.0495..47.8 rows=33477 loops=1)

EXPLAIN ANALYZE  
SELECT * FROM test_index
IGNORE INDEX(idx_hash_category)     -- Hash 인덱스 제거 
WHERE category='B';

-> Filter: (test_index.category = 'B')  (cost=10102 rows=49748) (actual time=0.0344..25.7 rows=33477 loops=1)
    -> Table scan on test_index  (cost=10102 rows=99495) (actual time=0.0323..21.2 rows=100000 loops=1)

CREATE TABLE hash_test (
    id INT AUTO_INCREMENT PRIMARY KEY,
    uuid VARCHAR(36),

    INDEX idx_hash_uuid USING HASH (uuid)
);

INSERT INTO hash_test (uuid)
SELECT 
    UUID()
FROM information_schema.tables AS a
CROSS JOIN information_schema.tables AS b
LIMIT 100000;

EXPLAIN ANALYZE  
SELECT * 
FROM hash_test  
WHERE uuid='eaeaf92b-fb22-11ef-9745-0242ac110002';

-> Covering index lookup on hash_test using idx_hash_uuid (uuid='eaeaf92b-fb22-11ef-9745-0242ac110002')  (cost=0.35 rows=1) (actual time=0.0349..0.0403 rows=1 loops=1)

EXPLAIN ANALYZE  
SELECT * 
FROM hash_test 
IGNORE INDEX(idx_hash_uuid)       -- Hash 인덱스 제거 
WHERE uuid='eaeaf92b-fb22-11ef-9745-0242ac110002';

-> Filter: (hash_test.uuid = 'eaeaf92b-fb22-11ef-9745-0242ac110002')  (cost=10079 rows=1) (actual time=16..34.3 rows=1 loops=1)
    -> Table scan on hash_test  (cost=10079 rows=99750) (actual time=0.303..23.4 rows=100000 loops=1)

EXPLAIN ANALYZE
SELECT * FROM test_index
WHERE MATCH(description) AGAINST('random');

-> Filter: (match test_index.`description` against ('random'))  (cost=0.35 rows=1) (actual time=15.7..89.4 rows=100000 loops=1)
    -> Full-text index search on test_index using idx_fulltext_description (description='random')  (cost=0.35 rows=1) (actual time=15.7..85.6 rows=100000 loops=1)

EXPLAIN ANALYZE  
SELECT * FROM test_index 
IGNORE INDEX(idx_fulltext_description)      -- Fulltext 인덱스 제거
WHERE MATCH(description) AGAINST('random');

-> Filter: (match test_index.`description` against ('random'))  (cost=10102 rows=11054) (actual time=0.571..27.3 rows=100000 loops=1)
    -> Table scan on test_index  (cost=10102 rows=99495) (actual time=0.568..19.5 rows=100000 loops=1)

EXPLAIN ANALYZE  
SELECT * FROM test_index  
WHERE description LIKE '%random%';

-> Filter: (test_index.`description` like '%random%')  (cost=10102 rows=11054) (actual time=0.0473..62.9 rows=100000 loops=1)
    -> Table scan on test_index  (cost=10102 rows=99495) (actual time=0.0422..32.8 rows=100000 loops=1)

EXPLAIN ANALYZE  
SELECT * FROM test_index 
IGNORE INDEX(idx_fulltext_description)       -- Fulltext 인덱스 제거
WHERE description LIKE '%random%';

-> Filter: (test_index.`description` like '%random%')  (cost=10102 rows=11054) (actual time=0.052..70.5 rows=100000 loops=1)
    -> Table scan on test_index  (cost=10102 rows=99495) (actual time=0.0452..36.9 rows=100000 loops=1)

CREATE TABLE fulltext_test ( 
    id INT AUTO_INCREMENT PRIMARY KEY, 
    description TEXT, 
    
    FULLTEXT INDEX idx_fulltext_description (description)
);

INSERT INTO fulltext_test (description)
SELECT CONCAT(
        ELT(FLOOR(1 + (RAND() * 5)),
            'AI',
            'Blockchain',
            'Quantum Computing',
            'Cybersecurity',
            'Cloud Computing'
        ),
        ' is transforming the world of ',
        ELT(FLOOR(1 + (RAND() * 5)),
            'finance',
            'healthcare',
            'automotive',
            'retail',
            'education'
        ),
        '. Experts predict it will impact over ',
        FLOOR(10 + (RAND() * 90)),
        ' million users by ',
        FLOOR(2025 + (RAND() * 10)),
        '.'
        )
FROM information_schema.tables AS a
CROSS JOIN information_schema.tables AS b
LIMIT 1000000;

EXPLAIN ANALYZE
SELECT * FROM fulltext_test 
WHERE MATCH(description) AGAINST('Blockchain');

 -> Filter: (match fulltext_test.`description` against ('Blockchain'))  (cost=0.35 rows=1) (actual time=5.64..35.9 rows=22668 loops=1)
    -> Full-text index search on fulltext_test using idx_fulltext_description (description='Blockchain')  (cost=0.35 rows=1) (actual time=5.63..34.3 rows=22668 loops=1)

EXPLAIN ANALYZE   
SELECT * 
FROM fulltext_test 
IGNORE INDEX(idx_fulltext_description) 
WHERE MATCH(description) AGAINST('Blockchain');

 -> Filter: (match fulltext_test.`description` against ('Blockchain'))  (cost=11596 rows=12572) (actual time=0.046..48.7 rows=22668 loops=1)
    -> Table scan on fulltext_test  (cost=11596 rows=113155) (actual time=0.0288..36.6 rows=114244 loops=1)

EXPLAIN ANALYZE 
SELECT * 
FROM btree_hash_test 
WHERE btree_column BETWEEN 100000 AND 200000;

-> Index range scan on btree_hash_test using idx_btree over (100000 <= btree_column <= 200000), with index condition: (btree_hash_test.btree_column between 100000 and 200000)  (cost=4535 rows=10078) (actual time=1.62..11.9 rows=10078 loops=1)

EXPLAIN ANALYZE 
SELECT * 
FROM btree_hash_test 
WHERE hash_column BETWEEN 100000 AND 200000;

-> Index range scan on btree_hash_test using idx_hash over (100000 <= hash_column <= 200000), with index condition: (btree_hash_test.hash_column between 100000 and 200000)  (cost=4475 rows=9943) (actual time=3.58..21.8 rows=9943 loops=1)

EXPLAIN ANALYZE 
SELECT * 
FROM btree_hash_test 
WHERE btree_column=146708;

-> Index lookup on btree_hash_test using idx_btree (btree_column=146708)  (cost=0.35 rows=1) (actual time=0.0424..0.0454 rows=1 loops=1)

EXPLAIN ANALYZE 
SELECT * 
FROM btree_hash_test 
WHERE hash_column=921585;

-> Index lookup on btree_hash_test using idx_hash (hash_column=921585)  (cost=0.35 rows=1) (actual time=0.0199..0.0213 rows=1 loops=1)

그냥 대충 B-Tree 써도 손해는 없어보인다.
다만, 속도차이를 보니 속도를 타이트하게 잡아야한다면, 다른 Index 를 고려해볼 필요는 있을 것 같다.

CREATE TABLE users (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    email VARCHAR(255) NOT NULL,
    name VARCHAR(100) NOT NULL,
    created_at DATETIME NOT NULL,
    INDEX idx_users_email (email),
    INDEX idx_users_created_at (created_at)
);

-- 인덱스 사용 (email = ?)
EXPLAIN SELECT * FROM users WHERE email = 'user@example.com';

-- created_at 범위 조회
EXPLAIN
SELECT *
FROM users
WHERE created_at >= '2025-01-01'
  AND created_at <  '2025-02-01';

-- ❌ 함수 사용 시 인덱스 사용 불가
SELECT * FROM users
WHERE DATE(created_at) = '2025-01-01';

-- ✅ 범위 조건으로 변경
SELECT * FROM users
WHERE created_at >= '2025-01-01 00:00:00'
  AND created_at <  '2025-01-02 00:00:00';

CREATE TABLE orders (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    amount DECIMAL(10,2) NOT NULL,
    created_at DATETIME NOT NULL,
    INDEX idx_orders_user_id (user_id)
);

EXPLAIN
SELECT u.id, u.email, o.amount
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE u.email = 'user@example.com';