hicucu/rdb-skill

관계형 데이터베이스 (엔진 중립적)

개요

엔진 중립적인 관계형 데이터베이스 모범 사례입니다. 원칙과 패턴은 한 번 작성되며, SQL 방언(dialect) 차이가 있는 지점(MSSQL 대 MySQL/MariaDB)만 인라인으로 표시하거나 방언 치트시트에 모았습니다. 정확성과 측정된 증거로 뒷받침된 가장 작은 변경을 목표로 최적화하세요.

사용 시기

• 스키마 설계 또는 검토(테이블, 키, 정규화, 데이터 타입).
• 인덱스 추가 또는 수정, 느린 쿼리나 전체 테이블 스캔 진단.
• 실행 계획을 읽어 병목 지점 찾기.
• 트랜잭션 격리, 잠금 또는 교착 상태 선택 또는 문제 해결.
• 대용량 결과 집합 페이지네이션, N+1 접근 제거.
• 프로덕션에 안전한 스키마 마이그레이션 계획.

적용 불가: 엔진 내부 심층 분석(InnoDB 버퍼 풀 같은 스토리지 엔진 내부, 벤더 전용 기능, T-SQL 전용 구문, 복제/샤딩 토폴로지). 해당 엔진의 공식 문서나 전용 단일 엔진 스킬을 사용하세요.

워크플로

1. 먼저 컨텍스트를 설정합니다. 어떤 엔진과 메이저 버전인가요? 읽기/쓰기 비율, 행 볼륨, 지연 시간 목표, OLTP 대 분석. 이에 따라 조언이 달라집니다.
2. 각 섹션에 링크된 관련 참조만 읽습니다.
3. 문제를 해결하는 가장 작은 변경을 장단점과 함께 제안합니다.
4. 증거로 검증합니다. — 변경 전후의 실행 계획과 행/시간 측정항목을 캡처합니다(references/execution-plans.md 참조). 경험 법칙이 아닙니다.
5. 프로덕션의 경우, 롤백 계획과 배포 후 검증을 포함합니다.

스키마 설계

• 관계를 명시적으로 모델링하고, 정규화(3NF/BCNF)로 시작하며 측정된 이유 없이는 비정규화하지 마세요. 모든 테이블에는 안정적인 기본 키가 필요합니다.
• 올바른 데이터 타입 중 가장 좁은 범위를 선택하고, 잘못된 상태를 애플리케이션 코드뿐만 아니라 스키마 수준(NOT NULL, UNIQUE, CHECK, FK)에서도 제한하세요.

참조: 정규화 · 키와 제약 조건 · 데이터 타입

인덱싱

• WHERE, JOIN, ORDER BY에 사용되는 열을 인덱싱합니다. 추측이 아닌 선택도(selectivity) 기준으로 합니다. 복합 인덱스 순서: 동등 조건 열 먼저, 그 다음 범위/정렬(최좌측 접두사 규칙). 범위 조건자는 이후 열의 인덱스 사용을 중단시킵니다.
• 커버링 인덱스는 테이블 조회를 피합니다. 사용되지 않거나 중복된 인덱스를 감사하고 제거하세요. 모든 인덱스는 쓰기 작업에 부담을 줍니다.

참조: 인덱싱 · 복합 인덱스

쿼리 최적화

• 조건자를 SARGable하게 유지하세요. WHERE절에서 인덱싱된 열에 함수/암시적 캐스트를 사용하지 마세요. 필요한 열만 선택하세요. 중복 제거가 필요 없는 경우 IN (서브쿼리) 대신 EXISTS, UNION 대신 UNION ALL을 선호하고, 대량 쓰기는 배치 처리하세요.
• 큰 OFFSET 대신 키셋(커서) 페이지네이션을 사용하세요. N+1 문제는 배치 처리나 조인으로 해결하세요.

참조: 쿼리 최적화 · 실행 계획 · 페이지네이션

트랜잭션과 잠금

• 트랜잭션을 짧게 유지하세요. I/O 및 느린 작업은 트랜잭션 밖에서 수행하세요. 교착 상태를 피하기 위해 일관된 순서로 행에 접근하고, 교착 상태를 예상하여 백오프(backoff)와 함께 재시도하세요.
• 엔진의 기본 격리 수준(엔진마다 다릅니다)과 각 수준이 허용하는 이상 현상을 알고 있어야 합니다. 잠금 읽기(FOR UPDATE)는 습관이 아닌 의도적으로 사용하세요.

참조: 트랜잭션과 격리 · 잠금과 교착 상태

마이그레이션과 DDL

• 스키마 변경은 추가 우선(additive-first) 및 하위 호환 가능하게 만드세요. 확장(expand) → 백필(backfill) → 축소(contract). 크거나 잠금을 유발하는 DDL은 온라인 전략과 롤백 경로가 필요합니다.

참조: 마이그레이션과 DDL

엔진 방언 차이점

자동 증가, 식별자 인용, 페이지네이션, 업서트(upsert), 문자열 함수, 현재 시간, EXPLAIN, 격리 기본값 등은 엔진마다 다릅니다. 이식성 있는 SQL을 작성하기 전에 대상 엔진의 구문을 확인하세요.

참조: 엔진 방언 치트시트

안전장치

• 포괄적인 규칙보다 측정된 증거(실행 계획, 측정항목)를 선호하세요.
• 동작이 엔진에 따라 달라지는 경우 엔진 및 메이저 버전을 명시하세요.
• 파괴적인 작업(DROP/DELETE/TRUNCATE 또는 되돌릴 수 없는 모든 마이그레이션) 전에는 명시적인 사람의 승인을 받으세요. 항상 백업이 있는지 먼저 확인하세요.