📚FOS Study
홈카테고리
홈카테고리

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • agents 페이지로 이동
    • custom-agents 페이지로 이동
    • Claude Code의 Skill 시스템 - 개발자를 위한 AI 자동화의 새로운 차원
    • 멀티모달 LLM (Multimodal Large Language Model)
  • architecture 페이지로 이동
    • 디자인 패턴
    • 분산 트랜잭션
    • 슬롯 게임 엔진 고도화 — 2025년 회고
  • css 페이지로 이동
    • FlexBox 페이지로 이동
  • database 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • 김영한의-실전-데이터베이스-설계 페이지로 이동
    • 커넥션 풀 크기는 얼마나 조정해야할까?
    • 인덱스 - DB 성능 최적화의 핵심
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • k8s-in-action 페이지로 이동
    • monitoring 페이지로 이동
  • go 페이지로 이동
    • Go 언어 기본 학습
  • http 페이지로 이동
    • HTTP Connection Pool
  • interview 페이지로 이동
    • 210812 페이지로 이동
    • 뱅크샐러드 AI Native Server Engineer
    • CJ 올리브영 지원 문항
    • CJ 올리브영 커머스플랫폼유닛 Back-End 개발 지원 자료
    • 마이리얼트립 - Platform Solutions실 회원주문개발 Product Engineer
    • NHN 서비스개발센터 AI서비스개발팀
    • nhn gameenvil console backend 직무 인터뷰 준비
    • 면접을 대비해봅시다
    • Tossplace Node.js Developer
    • 토스플레이스 Node.js 백엔드 컬처핏
  • java 페이지로 이동
    • jdbc 페이지로 이동
    • opentelemetry 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • Java의 로깅 환경
    • MDC (Mapped Diagnostic Context)
    • OpenTelemetry 란 무엇인가?
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • Data_Structures_and_Algorithms 페이지로 이동
    • Heap 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node.js
    • npm vs pnpm 선택기준은 무엇인가요?
    • `setImmediate()`
  • kafka 페이지로 이동
    • Kafka 기본
    • Kafka를 사용하여 **데이터 정합성**은 어떻게 유지해야 할까?
    • 메시지 전송 신뢰성
  • network 페이지로 이동
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • react 페이지로 이동
    • JSX 페이지로 이동
    • VirtualDOM 페이지로 이동
    • v16 페이지로 이동
  • redis 페이지로 이동
    • Redis
    • Redis Hash와 Lua 스크립트로 잭팟 누적 구현하기
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
📚FOS Study

개발 학습 기록을 정리하는 블로그입니다.

바로가기

  • 홈
  • 카테고리

소셜

  • GitHub
  • Source Repository

© 2025 FOS Study. Built with Next.js & Tailwind CSS

목록으로 돌아가기
🗄️database/ mysql

4장 아키텍처 (공부 중..)

약 4분
2026년 2월 3일
2026년 3월 22일 수정
GitHub에서 보기

4장 아키텍처 (공부 중..)

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

4.1 MySQL 엔진 아키텍처

  • MySQL 서버는 다른 DBMS에 비해 구조가 상당히 독특하다.
  • MySQL 서버는 크게 MySQL 엔진과 스토리지 엔진으로 구분할 수 있다.
  • 아래 구조도를 보면서 설명을 이어나가보자.

1. MySQL 전체 아키텍처 구조도

(1) MySQL 엔진

  • 클라이언트로부터의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 SQL 파서 및 전처리기, 쿼리의 최적화된 실행을 위한 옵티마이저가 중심을 이룬다.

(2) 스토리지 엔진

  • 실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽어오는 부분을 담당한다.
  • 스토리지 엔진은 여러 개를 동시에 사용할 수 있다.
    • 다음과 같이 테이블이 사용할 스토리지 엔진을 지정하면 이후 해당 테이블의 모든 읽기 작업이나 변경 작업은 정의된 스토리지 엔진이 처리한다
    CREATE TABLE test_table (fd1 INT, fd2 INT) ENGINE=InnoDB;
    

(3) 핸들러 API

  • MySQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 할 때는 각 스토리지 엔진에 쓰기 또는 읽기를 요청하는데, 이러한 요청을 핸들러(Handler) 요청이라고 한다. 여기에서 사용되는 API를 핸들러 API라고 부른다.
  • 핸들러 API를 통해 얼마나 많은 데이터(레코드) 작업이 있었는지는 SHOW GLOBAL STATUS LIKE 'Handler%'; 명령어로 확인해볼 수 있다.
    • 현재 Spring Batch 메타데이터만 관리하는 DB에 요청해본결과
    | Variable_name              | Value     |
    | -------------------------- | --------- |
    | Handler_commit             | 52788536  |
    | Handler_delete             | 1279      |
    | Handler_discover           | 0         |
    | Handler_external_lock      | 47244223  |
    | Handler_mrr_init           | 0         |
    | Handler_prepare            | 42530716  |
    | Handler_read_first         | 2641564   |
    | Handler_read_key           | 23349322  |
    | Handler_read_last          | 5         |
    | Handler_read_next          | 7360721   |
    | Handler_read_prev          | 2503      |
    | Handler_read_rnd           | 855       |
    | Handler_read_rnd_next      | 388011957 |
    | Handler_rollback           | 418       |
    | Handler_savepoint          | 0         |
    | Handler_savepoint_rollback | 0         |
    | Handler_update             | 10972053  |
    | Handler_write              | 191353285 |
    

2. MySQL 스레딩 구조

  • MySQL 서버는 스레드 기반으로 동작한다.
  • 크게 포그라운드(Foreground) 스레드와 백그라운드(Background) 스레드로 구분할 수 있다.
  • Thread per Connection으로 동작한다. (커넥션당 포그라운드 스레드 1개)
    • 일부 배포버전이나 엔터프라이즈 버전은 Thread Pool을 사용한다.
    • (내 생각) 보통 Application에서 커넥션 풀을 사용하므로 크게 문제되지는 않을 것 같아 보임

포그라운드 스레드 (클라이언트 스레드)

  • 각 클라이언트 사용자가 요청하는 쿼리 문장을 처리한다.

  • 클라이언트 사용자가 작업을 마치고 커넥션을 종료하면 해당 커넥션을 담당하던 스레드는 다시 스레드 캐시(Thread Cache)로 돌아간다.

  • 이떄 스레드 캐시에 유지할 수 있는 최대 스레드 개수는 thread_cache_size 시스템 변수로 설정한다.

  • (내 생각) Thread Pool과 Thread Cache가 다른건 뭐지?

    • Thread Cache - 종료된 스레드를 버리지 않고 보관했다가 재사용 - 스레드를 덜 만들 뿐, 많이 쓰는 건 그대로다.

      Connection 종료
      → Thread 종료 ❌
      → Thread Cache에 보관
      새 Connection
      → Thread 생성 ❌
      → Cache에서 재사용
      
    • Thread Pool

      • 커넥션 수와 스레드 수를 분리
      • 요청을 큐잉해서 제한된 스레드로 처리
      • 애초에 스레드를 많이 못 쓰게 막는다.
      Connection 1,000개
      ↓
      Request Queue
      ↓
      Worker Thread 32개
      

      정리, Thread Cache는 Thread-per-Connection 모델을 유지한 채
      스레드 생성 비용을 줄이는 기능이다.
      Thread Pool은 커넥션과 스레드를 분리해서
      서버의 동시성을 제어하는 아키텍처적인 변화이다.

database 카테고리의 다른 글 보기수정 제안하기

댓글

댓글을 불러오는 중...
목차
  • 4장 아키텍처 (공부 중..)
  • 4.1 MySQL 엔진 아키텍처
  • 1. MySQL 전체 아키텍처 구조도
  • (1) MySQL 엔진
  • (2) 스토리지 엔진
  • (3) 핸들러 API
  • 2. MySQL 스레딩 구조
  • 포그라운드 스레드 (클라이언트 스레드)