mysql

[초안] Aurora Serverless 환경의 커넥션 풀과 트랜잭션 예산 설계

Aurora Serverless는 "필요할 때만 늘어나고 줄어드는 MySQL"이라는 매력적인 약속을 한다. 하지만 그 약속은 애플리케이션 측 커넥션 풀 설계와 트랜잭션 점유 패턴이 받쳐줄 때만 성립한다. 풀을 잘못 잡으면 ACU가 천천히 따라오는 동안 커넥션 고갈로 503이 먼저 터지고, 트랜잭션을 길게 잡으면 scale-down이 막히면서 비용은 비용대로...

[초안] InnoDB Gap Lock & Next-Key Lock 심층 분석 — 구간 의미론부터 실무 디버깅까지

> 이 문서는 락의 '의미론' 에 집중한다. MVCC 일반론은 InnoDB MVCC, 데드락 해결/재시도/컨슈머 운영은 Deadlock Analysis를 참고한다. 여기서는 "왜 이 범위가 잠기는가", "어떤 락이 어떤 락과 충돌하는가", "로그의 어떤 표현이 어떤 상태인가"를 끝까지 파고든다. --- InnoDB에서 "락 때문에 발생한 장애"의 대부분은...

[초안] InnoDB MVCC 완전 분석 — Undo Log, Read View, 잠금, 그리고 Crash Recovery까지

--- InnoDB의 동시성 제어는 단순한 "락을 잡느냐 안 잡느냐"의 문제가 아니다. MySQL이 높은 읽기 처리량을 유지하면서도 트랜잭션 격리를 보장하는 핵심 메커니즘이 MVCC(Multi-Version Concurrency Control)다. 실무에서 발생하는 N+1 문제, 데드락, 팬텀 읽기, 갑작스러운 Undo Log 비대화, 슬로우 쿼리가 모두...

[초안] InnoDB Redo Log & Undo Log — WAL, Crash Recovery, Rollback 연계

InnoDB의 내구성(Durability)과 원자성(Atomicity)을 지탱하는 두 로그가 Redo Log와 Undo Log다. 애플리케이션 개발자 입장에서 두 로그가 어떤 목적을 가지고, 어떻게 협력해서 커밋/롤백/크래시 복구를 구현하는지 정리했다. MVCC 관점의 Undo 깊은 내용(버전 체인, Read View, Purge, 격리 수준)은 별도 문서...

[초안] MySQL / InnoDB 인덱스 허브

MySQL/InnoDB 인덱스는 면접과 실무 모두에서 "어떻게 동작하는가(구조)"와 "왜 내 쿼리는 느린가(운영)" 두 축으로 반복해서 등장한다. 이 문서는 인덱스 종합 허브로서 각 축의 핵심만 짧게 정리하고, 심화는 아래 상세 문서로 내려가게 한다. - 저장 구조 · 버퍼 풀 · MVCC 같은 엔진 내부는 → InnoDB 스토리지 엔진 아키텍처 - 복합...

[초안] MySQL EXPLAIN / EXPLAIN ANALYZE 완전 정복 — 실행 계획 읽기부터 Aurora 인터뷰 대비까지

백엔드 인터뷰에서 "N+1 문제를 어떻게 해결했나요?"에 "JOIN FETCH를 썼습니다"라고 답하면 반타작입니다. 면접관이 바로 묻습니다. "EXPLAIN으로 확인해봤나요? 실행 계획이 어떻게 달라졌나요?" EXPLAIN은 MySQL 옵티마이저가 쿼리를 실제로 어떻게 처리할지 보여주는 실행 계획(Execution Plan)입니다. 인덱스를 타는지, 풀스캔...

[초안] MySQL 데드락 실전 분석 — SQS 컨슈머 환경에서 InnoDB 락을 읽고 풀어내는 법

백엔드에서 데드락은 "가끔 나는 현상"이 아니다. 트래픽이 올라가고, 동일 로직이 컨슈머 워커 N대에서 병렬로 돌고, 트랜잭션이 살짝 길어지기 시작하면 숨어 있던 락 충돌이 한꺼번에 터진다. 그리고 그 시점은 대부분 프로모션, 쿠폰 발급, 알림 발송 같은 "돈과 고객 경험이 걸린 순간"이다. CJ OliveYoung 같은 이커머스 백엔드에서 실제로 터지는...

[초안] MySQL 복제와 샤딩: 시니어 백엔드 엔지니어를 위한 운영 실전 스터디

트래픽이 커지는 서비스에서 DB는 가장 먼저 무너지는 레이어다. 애플리케이션 서버는 수평 확장으로 대부분 해결되지만, 상태를 가진 DB는 단순히 인스턴스를 늘린다고 성능이 선형으로 증가하지 않는다. 복제(Replication)와 샤딩(Sharding)은 이 한계를 돌파하는 두 가지 축이다. 복제는 읽기 부하를 여러 노드로 분산시키고 장애 시 복구를 빠르게...

[초안] MySQL 복합 인덱스 완전 정복: 좌측 접두사 규칙부터 커버링 인덱스까지

단일 컬럼 인덱스는 직관적이다. userid에 인덱스를 걸면 WHERE userid = 42가 빠르다. 그런데 실제 서비스 쿼리는 대부분 조건이 2개 이상이다. WHERE userid = 42 AND status = 'ACTIVE', WHERE categoryid = 5 AND createdat >= '2025-01-01' ORDER BY createdat...

[초안] MySQL 인덱스 설계 1페이지 복습: B+Tree·복합 인덱스·커버링 인덱스

면접 직전 또는 운영 중 인덱스 리뷰가 필요할 때 5분 안에 훑을 수 있는 압축 복습용 카드다. 구조나 사례별 깊은 설명은 아래 상세 문서로 내려보내고, 여기서는 "어떤 원칙을 어떤 순서로 적용하는가"만 추린다. - 구조와 인덱스 종류 전반: b-tree-index.md - 좌측 접두사·범위 조건·정렬 최적화 심화: composite-index.md - 실...

[초안] 커머스 API를 위한 MySQL 인덱스와 EXPLAIN 실전 가이드

커머스 백엔드에서 가장 자주 마주치는 성능 문제는 거의 항상 인덱스와 실행 계획에서 출발한다. 주문 목록, 회원 쿠폰, 매장 메뉴처럼 조회 패턴이 정해져 있는 화면일수록 트래픽이 누적되고, 단일 쿼리의 비효율이 그대로 슬로우 쿼리 로그와 P99 응답 시간에 누적된다. CJ푸드빌처럼 매장/회원/메뉴/주문이 얽힌 도메인에서는 한 화면에서 수십만 row를 스캔하...

InnoDB 스토리지 엔진 아키텍처 (공부 중..)

InnoDB의 개략적인 구조는 다음과 같다. mermaid flowchart TB %% Memory Layer subgraph Memory BP[Buffer Pool] LB[Log Buffer] end %% Disk Layer subgraph Disk TS[Tablespace -...

InnoDB 트랜잭션과 잠금

Real MySQL 8.0 5장 내용을 정리한 문서. 개발자 입장에서 중요한 MVCC와 Lock 동작 방식에 집중했다. --- MySQL InnoDB 기본값은 REPEATABLE READ다. 나머지 수준은 설정을 바꾸지 않는 이상 실무에서 마주칠 일이 거의 없으니 표로만 정리한다. | 격리 수준 | Dirty Read | Non-Repeatable Read...

MySQL 서버 아키텍처

- MySQL 서버는 머리 역할을 담당하는 MySQL 엔진과, 손발 역할을 담당하는 스토리지 엔진으로 구분할 수 있다. - 스토리지 엔진은 핸들러 API를 만족하면 누구든지 스토리지 엔진을 구현해서 MySQL 서버에 추가해 사용할 수 있다. - 이번 장에서는 InnoDB 스토리지 엔진과 MyISAM 스토리지 엔진을 구분해서 살펴보자. - MySQL 서버는...

PublicKeyRetrieval is not allowed!

- 이 오류가 나는 원인은 무엇인가? - MySQL 8.x + cachingsha2password 인증방식에서 나오는 오류 - Public Key Retrieval is not allowed - The public key is not available Client side - 오류의 진짜 원인 - MySQL 8의 기본 인증 방식 : c...