-- 예시: (user_id, name, email) 복합 인덱스가 있을 때
SELECT name, email FROM users WHERE user_id = 100;

-- 이 쿼리는 인덱스만 읽고 결과를 반환할 수 있음 (커버링 인덱스)
-- 실제 테이블 접근 없이 초고속 처리! ⚡

-- 나쁜 예: 카디널리티가 낮은 컬럼이 앞에
CREATE INDEX idx_bad ON orders (status, user_id, order_date);
-- status는 '주문완료', '배송중', '취소' 등 몇 가지 값만 있음

-- 좋은 예: 카디널리티가 높은 컬럼이 앞에
CREATE INDEX idx_good ON orders (user_id, order_date, status);
-- user_id는 고유값이 많고, 자주 검색 조건으로 사용됨

-- 실제 쿼리
SELECT * FROM orders 
WHERE user_id = 12345 
  AND order_date >= '2024-01-01' 
  AND status = '배송중';
-- 이 쿼리는 idx_good 인덱스를 효과적으로 활용할 수 있어! ✨

EXPLAIN SELECT * FROM users WHERE email = 'test@example.com';

-- 결과 예시:
-- id | select_type | table | type | possible_keys | key     | rows | Extra
-- 1  | SIMPLE      | users | ref  | idx_email     | idx_email | 1   | Using index

-- ❌ 나쁜 예: 인덱스를 못 탐
SELECT * FROM users WHERE YEAR(created_at) = 2024;
SELECT * FROM products WHERE price * 1.1 > 10000;

-- ✅ 좋은 예: 인덱스를 탐
SELECT * FROM users WHERE created_at >= '2024-01-01' AND created_at < '2025-01-01';
SELECT * FROM products WHERE price > 10000 / 1.1;

-- ❌ 나쁜 예: 인덱스를 못 탐
SELECT * FROM users WHERE name LIKE '%홍길동%';
SELECT * FROM users WHERE name LIKE '%길동';

-- ✅ 좋은 예: 인덱스를 탐
SELECT * FROM users WHERE name LIKE '홍길동%';
-- 앞부분이 고정되어 있으면 인덱스 활용 가능!

-- ❌ 나쁜 예: 인덱스를 제대로 못 탐
SELECT * FROM users WHERE name = '홍길동' OR age = 30;

-- ✅ 좋은 예: UNION으로 분리
SELECT * FROM users WHERE name = '홍길동'
UNION
SELECT * FROM users WHERE age = 30;

-- 또는 IN 사용 (같은 컬럼일 때)
SELECT * FROM users WHERE user_id IN (1, 2, 3, 4, 5);

-- ❌ 나쁜 예: 인덱스를 못 탐
SELECT * FROM users WHERE status != 'active';
SELECT * FROM users WHERE status NOT IN ('active', 'pending');

-- ✅ 좋은 예: 긍정 조건으로 변경
SELECT * FROM users WHERE status IN ('inactive', 'deleted', 'banned');

-- user_id가 INT 타입인 경우
-- ❌ 나쁜 예: 문자열로 비교 (암묵적 형변환 발생)
SELECT * FROM users WHERE user_id = '12345';

-- ✅ 좋은 예: 올바른 타입으로 비교
SELECT * FROM users WHERE user_id = 12345;

-- ❌ 비효율적인 JOIN
SELECT u.*, o.*, p.*
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id
LEFT JOIN products p ON o.product_id = p.product_id;

-- ✅ 최적화된 JOIN
SELECT u.user_id, u.name, o.order_id, o.order_date, p.product_name
FROM users u
INNER JOIN orders o ON u.user_id = o.user_id
INNER JOIN products p ON o.product_id = p.product_id
WHERE o.order_date >= '2024-01-01'
  AND o.status = 'completed';
-- 필요한 컬럼만 선택, WHERE로 먼저 필터링, INNER JOIN 사용

-- ❌ 느린 상관 서브쿼리
SELECT u.user_id, u.name,
       (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.user_id) as order_count
FROM users u;
-- 각 사용자마다 서브쿼리가 실행됨 (N+1 문제)

-- ✅ 빠른 JOIN 방식
SELECT u.user_id, u.name, COUNT(o.order_id) as order_count
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id
GROUP BY u.user_id, u.name;
-- 한 번의 JOIN으로 처리

-- MySQL에서 사용되지 않는 인덱스 찾기
SELECT 
    s.table_schema,
    s.table_name,
    s.index_name,
    s.rows_read
FROM performance_schema.table_io_waits_summary_by_index_usage s
WHERE s.index_name IS NOT NULL
  AND s.rows_read = 0
  AND s.table_schema NOT IN ('mysql', 'performance_schema', 'information_schema')
ORDER BY s.table_schema, s.table_name;

-- MySQL
ANALYZE TABLE users;

-- PostgreSQL
ANALYZE users;

-- SQL Server
UPDATE STATISTICS users;

-- MySQL (InnoDB)
OPTIMIZE TABLE users;

-- SQL Server
-- 재구성
ALTER INDEX idx_user_email ON users REORGANIZE;

-- 재구축
ALTER INDEX idx_user_email ON users REBUILD;

-- 초기 쿼리 (느림 🐢)
SELECT * FROM experts
WHERE category = '프로그래밍'
  AND region = '서울'
  AND rating >= 4.0
ORDER BY last_active_date DESC
LIMIT 20;

-- 실행 시간: 8.5초
-- 문제: 인덱스 없음, Full Table Scan

CREATE INDEX idx_expert_search 
ON experts (category, region, rating, last_active_date);

-- 컬럼 순서 이유:
-- 1. category: 카디널리티 중간, 필수 조건
-- 2. region: 카디널리티 중간, 필수 조건
-- 3. rating: 범위 조건
-- 4. last_active_date: ORDER BY에 사용

-- 최적화된 쿼리 (빠름 🚀)
SELECT expert_id, name, category, region, rating, last_active_date
FROM experts
WHERE category = '프로그래밍'
  AND region = '서울'
  AND rating >= 4.0
ORDER BY last_active_date DESC
LIMIT 20;

-- 실행 시간: 0.02초
-- 개선: 425배 빠름!
-- Using index (커버링 인덱스 활용)

-- 초기 쿼리 (매우 느림 🐌)
SELECT t.*, u.name as user_name, e.name as expert_name
FROM transactions t
LEFT JOIN users u ON t.user_id = u.user_id
LEFT JOIN experts e ON t.expert_id = e.expert_id
WHERE t.user_id = 12345
  AND t.created_at >= DATE_SUB(NOW(), INTERVAL 3 MONTH)
ORDER BY t.created_at DESC;

-- 실행 시간: 15초
-- 문제: 비효율적인 JOIN, 인덱스 미활용

-- transactions 테이블
CREATE INDEX idx_user_date ON transactions (user_id, created_at DESC);

-- users, experts 테이블 (이미 PK 인덱스 있음)
-- user_id, expert_id는 이미 Primary Key로 인덱스됨

-- 최적화된 쿼리 (빠름 🚀)
SELECT 
    t.transaction_id,
    t.amount,
    t.status,
    t.created_at,
    u.name as user_name,
    e.name as expert_name
FROM transactions t
INNER JOIN users u ON t.user_id = u.user_id
INNER JOIN experts e ON t.expert_id = e.expert_id
WHERE t.user_id = 12345
  AND t.created_at >= DATE_SUB(NOW(), INTERVAL 3 MONTH)
ORDER BY t.created_at DESC
LIMIT 50;

-- 실행 시간: 0.05초
-- 개선: 300배 빠름!
-- 변경사항:
-- 1. 필요한 컬럼만 SELECT
-- 2. LEFT JOIN → INNER JOIN (NULL 데이터 없음)
-- 3. LIMIT 추가 (페이징)
-- 4. 인덱스 활용

-- 초기 쿼리 (엄청 느림 😱)
SELECT 
    s.service_id,
    s.title,
    (SELECT COUNT(*) FROM service_views WHERE service_id = s.service_id 
     AND viewed_at >= DATE_SUB(NOW(), INTERVAL 7 DAY)) as view_count,
    (SELECT COUNT(*) FROM service_likes WHERE service_id = s.service_id) as like_count,
    (SELECT COUNT(*) FROM transactions WHERE service_id = s.service_id 
     AND created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY)) as transaction_count
FROM services s
WHERE s.status = 'active'
ORDER BY (view_count + like_count * 2 + transaction_count * 5) DESC
LIMIT 10;

-- 실행 시간: 45초
-- 문제: N+1 문제, 상관 서브쿼리 남발

-- 주간 통계 테이블 생성
CREATE TABLE service_weekly_stats (
    service_id INT PRIMARY KEY,
    view_count INT DEFAULT 0,
    like_count INT DEFAULT 0,
    transaction_count INT DEFAULT 0,
    popularity_score INT DEFAULT 0,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_popularity (popularity_score DESC, updated_at)
);

-- 배치 작업으로 1시간마다 업데이트
INSERT INTO service_weekly_stats (service_id, view_count, like_count, transaction_count, popularity_score)
SELECT 
    s.service_id,
    COALESCE(v.view_count, 0) as view_count,
    COALESCE(l.like_count, 0) as like_count,
    COALESCE(t.transaction_count, 0) as transaction_count,
    (COALESCE(v.view_count, 0) + COALESCE(l.like_count, 0) * 2 + COALESCE(t.transaction_count, 0) * 5) as popularity_score
FROM services s
LEFT JOIN (
    SELECT service_id, COUNT(*) as view_count
    FROM service_views
    WHERE viewed_at >= DATE_SUB(NOW(), INTERVAL 7 DAY)
    GROUP BY service_id
) v ON s.service_id = v.service_id
LEFT JOIN (
    SELECT service_id, COUNT(*) as like_count
    FROM service_likes
    GROUP BY service_id
) l ON s.service_id = l.service_id
LEFT JOIN (
    SELECT service_id, COUNT(*) as transaction_count
    FROM transactions
    WHERE created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY)
    GROUP BY service_id
) t ON s.service_id = t.service_id
WHERE s.status = 'active'
ON DUPLICATE KEY UPDATE
    view_count = VALUES(view_count),
    like_count = VALUES(like_count),
    transaction_count = VALUES(transaction_count),
    popularity_score = VALUES(popularity_score),
    updated_at = CURRENT_TIMESTAMP;

-- 최적화된 쿼리 (초고속 ⚡)
SELECT 
    s.service_id,
    s.title,
    s.thumbnail,
    st.view_count,
    st.like_count,
    st.transaction_count,
    st.popularity_score
FROM services s
INNER JOIN service_weekly_stats st ON s.service_id = st.service_id
WHERE s.status = 'active'
ORDER BY st.popularity_score DESC
LIMIT 10;

-- 실행 시간: 0.003초
-- 개선: 15,000배 빠름!
-- 트레이드오프: 실시간성은 약간 떨어지지만 (1시간 지연)
--              사용자 경험은 훨씬 좋아짐

-- 날짜 기준 파티셔닝 예시
CREATE TABLE transactions (
    transaction_id BIGINT AUTO_INCREMENT,
    user_id INT NOT NULL,
    amount DECIMAL(10,2),
    created_at DATETIME NOT NULL,
    PRIMARY KEY (transaction_id, created_at),
    INDEX idx_user (user_id)
)
PARTITION BY RANGE (YEAR(created_at)) (
    PARTITION p2022 VALUES LESS THAN (2023),
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION p2025 VALUES LESS THAN (2026),
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

-- 2024년 데이터만 조회 (p2024 파티션만 스캔)
SELECT * FROM transactions
WHERE created_at >= '2024-01-01' AND created_at < '2025-01-01';

-- 2022년 데이터 삭제 (파티션 통째로 삭제, 매우 빠름!)
ALTER TABLE transactions DROP PARTITION p2022;

// Node.js + Redis 캐싱 예시
const redis = require('redis');
const client = redis.createClient();

async function getPopularServices() {
    const cacheKey = 'popular_services:top10';
    
    // 1. 캐시 확인
    const cached = await client.get(cacheKey);
    if (cached) {
        console.log('캐시 히트! 🎯');
        return JSON.parse(cached);
    }
    
    // 2. 캐시 미스 - DB 조회
    console.log('캐시 미스, DB 조회 중... 🔍');
    const result = await db.query(`
        SELECT service_id, title, popularity_score
        FROM service_weekly_stats
        ORDER BY popularity_score DESC
        LIMIT 10
    `);
    
    // 3. 결과를 캐시에 저장 (5분 TTL)
    await client.setex(cacheKey, 300, JSON.stringify(result));
    
    return result;
}

// 첫 호출: DB 조회 (0.003초)
// 이후 호출: 캐시 반환 (0.0001초) - 30배 빠름!

-- 정규화된 구조 (JOIN 필요)
SELECT u.name, COUNT(o.order_id) as order_count
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id
GROUP BY u.user_id, u.name;

-- 비정규화된 구조 (JOIN 불필요)
-- users 테이블에 order_count 컬럼 추가
SELECT name, order_count FROM users WHERE user_id = 123;

-- 주문이 생길 때마다 users.order_count도 업데이트
BEGIN;
INSERT INTO orders (user_id, product_id, amount) VALUES (123, 456, 50000);
UPDATE users SET order_count = order_count + 1 WHERE user_id = 123;
COMMIT;

-- ❌ 느린 방법: 하나씩 INSERT (N번의 쿼리)
INSERT INTO logs (user_id, action, created_at) VALUES (1, 'login', NOW());
INSERT INTO logs (user_id, action, created_at) VALUES (2, 'view', NOW());
INSERT INTO logs (user_id, action, created_at) VALUES (3, 'purchase', NOW());
-- ... 10,000번 반복

-- ✅ 빠른 방법: 벌크 INSERT (1번의 쿼리)
INSERT INTO logs (user_id, action, created_at) VALUES
(1, 'login', NOW()),
(2, 'view', NOW()),
(3, 'purchase', NOW()),
-- ... 10,000개를 한 번에
(10000, 'logout', NOW());

-- 성능 차이: 100배 이상!