MySQL 스레딩 구조

MySQL은 스레드(Thread) 기반으로 동작되도록 설계되었다. postgresql과 같은 RDBMS가 process 기반으로 동작하는 것과는 대비된다.

Process와 Thread의 차이

구분	Process	Thread
메모리 공간	각자 독립	같은 프로세스 내에서 공유
생성 비용	무거움 (메모리 복사, PID 할당 등)	가벼움
컨텍스트 스위칭	느림 (메모리 매핑 교체)	빠름 (CPU 레지스터/스택만 교체)
격리성	강함 (하나 죽어도 다른 프로세스에 영향 없음)	약함 (한 스레드가 죽으면 프로세스 전체가 죽을 수 있음)
통신	IPC 필요 (파이프, 소켓, 공유 메모리 등)	변수 공유만으로 가능

MySQL이 Thread 기반인 이유

MySQL는 클라이언트가 연결될 때마다 새 thread를 하나씩 할당하는 구조로 동작하며, 이를 "Connection Thread"라고 한다.

1. 연결 생성/해제가 빠르다

Thread는 웹 애플리케이션처럼 짧은 연결이 수없이 들어오는 환경에 유리하다. process를 fork하는 비용보다 thread를 만드는 비용이 상대적으로 저렴하기 때문이다.

2. 메모리 사용량이 적다

InnoDB 버퍼 풀 같은 공용 자원을 thread들이 메모리에서 그대로 공유한다. process 기반이면 공유 메모리(shared memory)를 따로 만들어야 하며, PostgreSQL이 이러한 방식으로 동작한다.

3. 동시 처리량(throughput)이 높다

컨텍스트 스위칭이 가벼우니, 수천 개의 동시 연결도 비교적 부담 없이 처리할 수 있다.

포그라운드 vs 백그라운드

MySQL 서버 내부의 스레드는 역할에 따라 크게 두 종류로 나뉜다.

구분	역할 요약	개수
포그라운드 스레드	클라이언트의 요청(쿼리)을 직접 처리	접속한 클라이언트 수만큼
백그라운드 스레드	서버 내부의 비동기 작업(디스크 I/O, 로그 기록 등)	스토리지 엔진/설정에 따라 다수

포그라운드 스레드 (Foreground Thread / Client Thread)

클라이언트가 MySQL 서버에 접속하면, 그 연결을 전담할 스레드가 하나 할당된다. 이 스레드를 포그라운드 스레드 또는 클라이언트 스레드라고 부른다.

포그라운드 스레드의 역할은 아래와 같다.

클라이언트가 보낸 쿼리를 파싱하고 실행하며, 결과를 돌려준다.
데이터를 읽을 때는 먼저 버퍼 풀(InnoDB Buffer Pool)이나 캐시를 확인하고, 거기에 없을 때만 디스크에서 직접 읽어온다.
클라이언트가 연결을 끊으면 스레드는 종료되지 않고, 스레드 캐시(Thread Cache) 로 돌아가 다음 연결을 기다린다. 이 덕분에 매 연결마다 스레드를 새로 만들지 않아도 된다.
단, 캐시에 일정 개수 이상이 쌓이면 초과분은 종료시켜 메모리를 회수한다. 이 한도는 thread_cache_size 시스템 변수로 제어한다.

중요한 포인트는 포그라운드 스레드는 디스크에 데이터를 직접 쓰지 않는다는 점이다. 데이터 변경은 일단 메모리(버퍼 풀)에만 반영하고, 실제 디스크 쓰기는 백그라운드 스레드에게 맡긴다. 이를 지연된 쓰기(Delayed Write) 라고 하며, 덕분에 클라이언트는 디스크 I/O를 기다리지 않고 빠르게 응답을 받을 수 있다.

백그라운드 스레드 (Background Thread)

백그라운드 스레드는 클라이언트와 직접 통신하지 않고, 서버 내부 유지보수성 작업을 담당한다. InnoDB의 경우 대표적으로 다음과 같은 스레드들이 있다.

인서트 버퍼(Insert Buffer)를 병합하는 스레드
로그를 디스크로 기록하는 스레드
버퍼 풀의 더티 페이지를 디스크에 기록하는 스레드 (innodb_write_io_threads)
데이터를 디스크에서 버퍼로 읽어오는 스레드 (innodb_read_io_threads)
잠금이나 데드락을 모니터링하는 스레드

MySQL 5.5 이전에는 백그라운드 스레드의 종류와 수가 적었지만, 5.5부터 멀티 스레드 I/O를 지원하면서 위 변수들로 스레드 수를 늘릴 수 있게 되었다. 특히 SSD처럼 빠른 디스크를 사용할 때는 일반 HDD보다 동시에 처리 가능한 I/O가 많기 때문에, innodb_read_io_threads와 innodb_write_io_threads를 충분히 늘려야 디스크 성능을 제대로 활용할 수 있다

스레드 기반의 단점

MySQL은 하나의 프로세스에 여러 스레드를 나눠 프로그램을 동작시키는 형태이므로, 잘못된 쿼리 등으로 인해 프로세스가 죽는다먼 MySQL 서버 전체가 죽을 수도 있는 위험이 존재한다. 또한 스레드 간 자원 공유 때문에 Race Condition이나 deadlock 같은 동시성 문제가 프로세스 기반 RDBMS 대비 더 많이 발생할 수도 있다.