DB27

• 

  [MySQL] 인덱스 심화 2 — ORDER BY가 인덱스를 타는 조건, 암시적 형변환, 인덱스 없는 UPDATE의 락 확산 1. 문서 제목MySQL 인덱스 심화 2 — ORDER BY가 인덱스를 타는 조건, 암시적 형변환, 인덱스 없는 UPDATE의 락 확산2. 기술 개요 요약인덱스의 기본 구조(B+Tree, 클러스터드/세컨더리, 복합 인덱스 컬럼 순서)를 이해한 다음 단계는 경계 사례다. "인덱스가 있는데도 안 타는 쿼리"와 반대로 "안 탈 것 같은데 타는 쿼리"를 정확히 가르는 기준, 그리고 인덱스가 조회 성능을 넘어 UPDATE의 락 범위까지 좌우한다는 사실이 이 문서의 주제다. 판단 기준은 두 가지로 압축된다: ① 인덱스는 "저장된 정렬"이므로, 그 정렬을 그대로 활용할 수 있는 형태의 조건/정렬만 인덱스를 탄다 ② 가공되는 쪽이 컬럼이면 못 타고, 비교값이면 탄다.다루는 질문:#질문핵심 키워드1복합 인덱스 (a,b,.. DB/MySQL 2026. 7. 12.

• 

  [Redis] 분산락 정리 — Watchdog·TTL·Fencing Token·SET NX 취약점 1. 문서 제목Redis 분산락 정리 — Watchdog·TTL·Fencing Token·SET NX 취약점2. 기술 개요 요약분산락(Distributed Lock)은 여러 서버 인스턴스가 같은 자원에 동시 접근하는 것을 막기 위해 Redis 같은 외부 시스템을 조정자로 쓰는 방식이다. SET key value NX EX ttl 같은 명령 하나로 구현이 간단해 보이지만, 실제로는 "락을 쥔 프로세스가 멈췄을 때", "TTL이 만료됐는데 원래 소유자가 살아 돌아왔을 때" 같은 경계 상황에서 정합성이 깨지기 쉽다. 이 문서는 그 경계 상황들을 원인 순서대로 정리한다.3. 핵심 개념 정리개념설명실무 포인트Watchdog락 보유 중 TTL을 주기적으로 연장하는 백그라운드 스레드(Redisson 기본 30초 le.. DB/Redis 2026. 7. 12.

• 

  [MySQL] 인덱스 심화 — 10%룰, B+Tree 리밸런싱, 복합 인덱스 컬럼 순서 1. 문서 제목MySQL 인덱스 심화 — 10%룰, B+Tree 리밸런싱, 복합 인덱스 컬럼 순서2. 기술 개요 요약인덱스를 "있으면 무조건 빠르다"로 이해하면 실전 튜닝에서 막힌다. 옵티마이저가 인덱스 대신 풀스캔을 택하는 기준, B+Tree가 삽입·삭제마다 스스로 균형을 맞추는 방식, 복합 인덱스에서 컬럼 순서를 정하는 진짜 기준까지 알아야 EXPLAIN 결과를 해석하고 인덱스를 설계할 수 있다. 이 문서는 이 세 가지를 정리한다. 인덱스 레인지 스캔과 랜덤 I/O, covering index는 이미 다뤘으므로 여기서는 다루지 않는다.3. 핵심 기능/개념 정리개념설명실무 포인트인덱스 vs 풀스캔 임계점("10%룰")조회 대상 로우 비율이 일정 수준을 넘어 세컨더리 인덱스의 랜덤 I/O 누적 비용이 순.. DB/MySQL 2026. 7. 12.

• 

  DB 커넥션 풀 사이징과 데드락 — API가 느려질 때 원인을 좁히는 순서 1. 문서 제목DB 커넥션 풀 사이징과 데드락 — API가 느려질 때 원인을 좁히는 순서2. 기술 개요 요약DB 성능 저하는 보통 "쿼리 문제 / 락 경합 / 커넥션 풀 고갈 / 리소스 부족" 네 갈래 중 하나에서 시작된다. 이 문서는 그중 커넥션 풀 사이징의 기준(코어 수 vs 쓰레드 수)과 락 경합의 대표 사례인 데드락의 발생 원리, 그리고 API 지연이 발생했을 때 실무에서 원인을 좁혀가는 순서를 정리한다. SHOW PROCESSLIST와 세부 모니터링 지표는 이미 다뤘으므로 여기서는 커넥션 풀 사이징 원리와 데드락에 집중한다.3. 핵심 기능/개념 정리개념설명실무 포인트커넥션 풀 사이징 공식의 "쓰레드"HikariCP 등에서 인용되는 (core_count * 2) + effective_spindle.. DB/MySQL 2026. 7. 12.

• 

  캐싱 설계 가이드: Cache-Aside, Write 전략, Cache Stampede 방어 1. 문서 제목캐싱 설계 가이드: Cache-Aside, Write 전략, Cache Stampede 방어2. 기술 개요캐시(Cache)는 자주 조회되지만 매번 다시 계산하거나 DB를 조회하기엔 비싼 데이터를, 더 빠른 저장소(메모리, Redis 등)에 사본으로 미리 준비해두는 것이다. 목적은 단순하다 — 응답 속도를 올리고 원본 저장소(DB)의 부하를 줄이는 것.문제는 캐시를 쓰는 순간 "진짜 데이터(DB)"와 "사본(캐시)" 두 벌이 생긴다는 점이다. 원본이 바뀌었는데 사본이 안 바뀌면 사용자는 낡은 값을 보게 된다. 그래서 캐싱 설계는 사실상 아래 두 질문으로 귀결된다.읽을 때, 캐시에 없으면 누가 채우는가? (읽기 전략)원본이 바뀌었을 때, 캐시를 어떻게 처리하는가? (쓰기 전략)"컴퓨터 과학에서.. DB 2026. 7. 11.

• 

  샤딩 환경의 조인, 분산 트랜잭션, Saga 패턴 정리 1. 문서 제목샤딩 환경의 조인, 분산 트랜잭션, Saga 패턴 정리2. 기술 개요 요약샤딩은 데이터를 여러 독립적인 DB 서버로 나누어 저장하는 수평 분할 방식이다. 쓰기 트래픽과 데이터량을 분산할 수 있지만, 단일 DB 안에서는 자연스럽게 처리되던 JOIN과 트랜잭션이 샤드 경계를 넘는 순간 복잡해진다. 서로 다른 샤드는 물리적으로 다른 서버, 다른 커넥션, 다른 트랜잭션 경계를 가지기 때문이다.샤딩 환경에서 크로스 샤드 조인은 애플리케이션 레벨 조인, 비정규화, 분산 쿼리 엔진, CQRS 기반 조회 모델 등으로 해결한다. 여러 샤드에 걸친 트랜잭션은 전통적으로 2PC(Two-Phase Commit)를 사용할 수 있지만, 블로킹과 가용성 저하 문제가 크다. 실무에서는 강한 일관성을 일부 포기하고 로컬.. DB/PostgreSQL 2026. 7. 11.

• 

  [MySQL] 인덱스 레인지 스캔, 랜덤 I/O, 검색엔진 도입 기준 정리 1. 문서 제목인덱스 레인지 스캔, 랜덤 I/O, 검색엔진 도입 기준 정리2. 기술 개요 요약인덱스 레인지 스캔은 B-Tree 계열 인덱스에서 특정 범위의 키를 찾아 순서대로 읽는 방식이다. WHERE age > 20, BETWEEN, LIKE 'abc%'처럼 범위 조건을 사용할 때 대표적으로 등장한다. 다만 InnoDB에서 secondary index를 사용할 경우 인덱스 리프에는 실제 row 전체가 아니라 primary key 값이 들어 있고, 이 primary key로 clustered index를 다시 찾아 실제 row를 읽는다. 이 과정에서 데이터 페이지 접근이 흩어지면 랜덤 I/O가 발생한다.반면 쿼리에 필요한 컬럼이 모두 인덱스에 포함되어 있으면 테이블 row를 다시 읽지 않아도 되므로 co.. DB/MySQL 2026. 7. 11.

• 

  [MySQL] Replication과 InnoDB Cluster, Sharding은 무엇이 다를까? 1. 문서 제목MySQL Replication과 InnoDB Cluster, Sharding은 무엇이 다를까?2. 기술 개요 요약DB 확장과 고가용성을 이야기할 때 Clustering, Replication, Sharding이 자주 함께 등장한다. 세 개념은 모두 DB를 여러 대로 구성한다는 공통점이 있지만 목적과 데이터 배치 방식이 다르다. Clustering은 주로 장애 전환과 가용성을 위해 여러 노드를 하나의 서비스처럼 묶는 개념이고, Replication은 동일한 데이터를 여러 서버에 복제해 읽기 분산과 장애 대응을 돕는다. Sharding은 데이터를 여러 조각으로 나누어 서로 다른 서버에 저장함으로써 쓰기 부하와 저장 용량을 분산한다.핵심 구분 기준은 “데이터를 몇 벌 갖고 있는가”와 “각 서버.. DB/MySQL 2026. 7. 11.

• 

  [MySQL] SHOW PROCESSLIST와 DB 모니터링 메트릭 정리 1. 문서 제목MySQL SHOW PROCESSLIST와 DB 모니터링 메트릭 정리2. 기술 개요 요약DB 장애나 성능 저하가 발생했을 때는 먼저 현상을 관찰하고, 현재 DB 내부에서 어떤 세션이 실행 중인지 확인한 뒤, 원인을 쿼리 문제·락 경합·리소스 부족으로 분류해야 한다. MySQL의 SHOW PROCESSLIST는 서버 내부 스레드가 현재 수행 중인 작업을 보여주는 기본 진단 명령어다. 여기에 QPS, Slow Query, InnoDB Buffer Pool Hit Ratio, Replication Lag, Lock Wait, 활성 커넥션 수 같은 메트릭을 함께 보면 장애 원인을 더 빠르게 좁힐 수 있다.이 문서는 면접 답변과 실무 운영 모두에서 사용할 수 있도록 SHOW PROCESSLIST 해.. DB/MySQL 2026. 7. 10.

• 

  [MySQL] EXPLAIN 실행계획과 파티셔닝 정리 1. 문서 제목MySQL EXPLAIN 실행계획과 파티셔닝 정리2. 기술 개요 요약EXPLAIN은 MySQL 옵티마이저가 SQL을 어떤 방식으로 실행할 계획인지 보여주는 진단 도구다. 실제 성능 문제를 볼 때는 type, key, rows, filtered, Extra, partitions 같은 컬럼을 함께 확인해야 한다. 특히 type = ALL, 과도하게 큰 rows, Using filesort, Using temporary는 튜닝 후보가 될 수 있다.파티셔닝은 하나의 큰 테이블을 같은 MySQL 서버 안에서 여러 물리 파티션으로 나누는 기능이다. 핵심 효과는 인덱스처럼 “빠르게 찾는 것”이라기보다, 조건과 관련 없는 파티션을 제외하는 partition pruning을 통해 “처음부터 볼 데이터 덩어.. DB/MySQL 2026. 7. 10.

• MongoDB(Mongoose) → PostgreSQL(Prisma) 마이그레이션 가이드 (Service Layer 포함) 1. 문서 제목 제안MongoDB(Mongoose) → PostgreSQL(Prisma) 마이그레이션 가이드 (Service Layer 포함)2. 기술 개요 요약MongoDB(Mongoose) 기반의 NoSQL 구조에서 PostgreSQL(Prisma ORM) 기반의 관계형 데이터 구조로 전환하면서, 타입 안정성, 데이터 정합성, 개발자 경험(DX)을 개선하고 Service Layer를 도입해 아키텍처의 유지보수성과 확장성을 높이는 것이 핵심이다. 특히 Prisma는 스키마 기반 타입 생성과 직관적인 마이그레이션 워크플로우를 제공하여 생산성을 크게 향상시킨다.3. 핵심 기능 / 개념 정리3.1 Mongoose vs Prisma 비교항목Mongoose (MongoDB)Prisma (PostgreSQL)데이.. DB 2026. 3. 22.

• 데드락(Deadlock) — MikroORM/PostgreSQL 실전 예제로 이해하기 데드락(Deadlock) 완전 정복 — MikroORM/PostgreSQL 실전 예제로 이해하기데드락은 이론적으로는 단순하지만, 실무에서는 예상치 못한 곳에서 터진다. 이 글에서는 데드락의 발생 조건을 정리하고, MikroORM + PostgreSQL 환경에서 실제로 데드락이 발생하는 3가지 패턴을 쿼리 레벨까지 추적하며, 각 해결 방법의 트레이드오프를 다룬다.데드락이란두 개 이상의 트랜잭션이 서로가 잡고 있는 리소스를 기다리면서 영원히 진행하지 못하는 상태다. 둘 다 상대방이 먼저 놓아주길 기다리지만, 아무도 양보하지 않는다.데드락 발생의 4가지 조건데드락은 아래 4가지가 동시에 성립해야 발생한다. 하나라도 깨뜨리면 데드락은 발생하지 않는다.1. 상호 배제 (Mutual Exclusion) — 리소스를.. DB 2026. 1. 5.