2025-08-11
오늘 배운 것
4.1.1 MySQL의 전체 구조
- MySQL(서버)
- MySQL 엔진
- sql 인터페이스
- sql 파서
- sql 옵티마이저
- 캐시 & 버퍼
- 스토리지 엔진
4.1.1.1 MySQL 엔진
- MySQL 엔진 구성요소
- 커넥션 핸들러 : 클라이언트로부터의 접속 및 쿼리 요청을 처리
- SQL 파서 및 전처리기
- 옵티마이저 : 쿼리의 최적화된 실행
- 특징 : MySQL은 표준 SQL(ANSI SQL) 문법을 지원하기 때문에 표준 문법에 따라 작성된 쿼리는 타 DBMS와 호환되어 실행 가능하다
4.1.1.2 스토리지 엔진
- 스토리지 엔진 : 실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽기를 전담
- mysql 엔진은 하나이지만 스토리지 엔진은 여러 개를 동시에 사용할 수 있다.
4.1.1.3 핸들러 API
- 핸들러 API : MySQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 할 때 각 스토리지 엔진에 쓰기 또는 읽기를 요청하는데 사용되는 API
4.1.2 MySQL 스레딩 구조
- 프로세스 기반이 아닌 스레드 기반으로 작동
- 구분
- 포그라운드(foreground) 스레드
- 백그라운드(background) 스레드
4.1.2.1 포그라운드 스레드(클라이언트 스레드)
- 포그라운드 스레드는 최소한 MySQL 서버에 접속된 클라이언트의 수만큼 존재
- 주로 각 클라이언트 사용자가 요청하는 쿼리 문장을 처리
- 클라이언트 사용자가 작업을 마치고 커넥션 종료하면 해당 커넥션을 담당하던 스레드는 다시 스레드 캐시로 되돌아감
- 이 때, 이미 스레드 캐시에 일정 개수 이상의 대기 스레드 존재시, 해당 스레드를 그냥 종료시켜 일정 개수의 스레드 수를 유지
- 데이터를 MySQL의 데이터 버퍼나 캐시로부터 가져오며, 버퍼나 캐시에 없는 경우에는 직접 디스크의 데이터나 인덱스 파일로 부터 데이터를 읽어와서 처리
4.1.2.2 백그라운드 스레드
- InnoDB에서 백그라운드로 처리되는 작업들
- 인서트 버퍼를 병합하는 스레드
- 로그를 디스크로 기록하는 스레드
- InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 스레드
- 데이터를 버퍼로 읽어오는 스레드
- 잠금이나 데드락을 모니터링하는 스레드
- 쓰기 버퍼링
- InnoDB는 쓰기작업을 버퍼링해서 일괄 처리
- MyISAM은 사용자 스레드가 쓰기 작업까지 함께 처리하도록 설계되어있기 때문에 일반적인 쿼리는 쓰기 버퍼링 기능을 사용할 수 없다.
4.1.3 메모리 할당 및 사용 구조
- 글로벌 메모리 영역
- 서버 시작할 때 운영체제로부터 할당됨
- 실제로는 복잡하나 단순히 시스템 변수로 설정해둔 만큼 운영체제로부터 메모리 할당
4.1.3.1 글로벌 메모리 영역
- 클라이언트 스레드의 수와 무관하게 하나의 메모리 공간만 할당됨
- 필요에 따라 2개 이상도 가능하나 이는 클라이언트 스레드 수와 무관
- 생성된 글로벌 영역들은 모든 스레드에 의해 공유된다
- 대표적인 글로벌 메모리 영역
- 테이블 캐시
- InnoDB 버퍼 풀
- InnoDB 어댑티브 해시 인덱스
- InnoDB 리두 로그 버퍼
4.1.3.2 로컬 메모리 영역
- = 세션 메모리 영역, 클라이언트 메모리 영역
- 서버상 존재하는 클라이언트 스레드가 쿼리를 처리하는 데 사용하는 메모리 영역
- 각 클라이언트 스레드 별로 독립적으로 할당
- 절대 공유되어 사용되지 않음
- 각 쿼리의 용도별로 필요할 때만 공간이 할당되고 필요하지 않은 경우는 할당조차 안할 수도 있음
- 대표적인 글로벌 메모리 영역
- 순간 할당 후 다시 해제되는 공간
- 할당 상태로 남아있는 공간
4.1.4 플러그인 스토리지 엔진 모델
- MySQL은 다양한 요구 조건 만족을 위해 기본적으로 제공되는 스토리지 엔진 이외의 부가적인 기능을 더 제공하는 플러그인 모델을 가지고 있다.
- 이는 스토리지 엔진 뿐만 아니라 다양한 기능을 플러그인 형태로 지원
4.1.5 컴포넌트
- MySQL 8.0부터는 기존의 플러그인 아키텍처를 대체하기 위해 컴포넌트 아키텍처가 지원된다
- 플러그인 단점
- 플러그인은 오직 MySQL 서버와 인터페이스 할 수 있고, 플러그인 끼리는 통신 불가
- 플러그인은 MySQL 서버의 변수나 함수를 직접 호출하기 때문에 안전하지 않음(캡슐화 안됨)
- 플러그인은 상호 의존 관계를 설정할 수 없어서 초기화가 어려움
4.1.6 쿼리 실행 구조
- SQL 요청
- 쿼리 파서
- 전처리기
- 옵티마이저(쿼리변환, 비용 최적화, 실행계획 수립)
- 쿼리 실행기
- SQL 결과
4.1.6.1 쿼리 파서
- 사용자 요청으로 들어온 쿼리 문장을 토큰으로 분리해 트리 형태의 구조로 만들어 내는 작업
- 기본 문법 오류는 이 과정에서 발견되어 오류 메시지를 사용자에게 전달
4.6.1.2 전처리기
- 만들어진 트리에 구조적인 문제점이 있는지 확인
- 테이블 이름, 칼럼 이름, 내장 함수와 같은 개체를 매핑하여 해당 객체의 존재 여부와 객체의 접근 권한 확인
4.1.6.3 옵티마이저
- 사용자 요청으로 들어온 쿼리 문장을 저렴한 비용으로 가장 빠르게 처리할지를 결정
4.1.6.4 실행 엔진
- 만들어진 계획대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 역할 수행
4.1.6.5 핸들러(스토리지 엔진)
- 서버의 가장 밑단에서 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 디스크로부터 읽어오는 역할을 담당
- 핸들러가 결국 스토리지 엔진을 의미
4.1.7 복제
4.1.8 쿼리 캐시
- SQL의 실행 결과를 메모리에 캐시하고, 동일 SQL 쿼리가 실행되면 테이블을 읽지 않고 즉시 결과 반환
- 문제점
- 테이블의 데이터가 변경되면 캐시에 저장된 결과 중 변경된 테이블과 관련된 것들을 모두 삭제 → 동시처리 성능 저하
- 그래서 8.0부터 사라짐
4.1.9 스레드 풀
- 내부적으로 사용자의 요청을 처리하는 스레드 개수를 줄여서 동시 처리되는 요청이 많다 하더라도 MySQL 서버의 CPU가 제한된 개수의 스레드 처리에만 집중할 수 있게 해서 서버의 자원 소모를 줄이는 것이 목적
- 근데 사실 실제 서비스에서 눈에 띄는 성능 향상을 보여준 경우는 드뭄
- cpu 최적화를 위해 스레드를 줄이기 때문에 해당 스케줄링 과정에서 cpu시간을 제대로 확보하지 못해 쿼리 처리가 더 느려지는 사례도 발생 가능
- 그래도 제한된 수의 스레드만으로 cpu가 처리하도록 적절히 유도하면 cpu의 프로세서 친화도를 높이고 불필요한 컨텍스트 스위칭을 줄일 수 있어 오버헤드를 낮출 수 있음
- 일반적으로 cpu의 코어개수와 스레드 그룹의 개수를 맞추는 것이 cpu 프로세서 친화도를 높이는데 좋다
- 서버가 처리해야할 요청이 생기면 스레드 풀로 처리를 이관
- 만약 이미 스레드 풀이 처리중인 작업이 있는경우
- 시스템 변수에 설정된 개수만큼 추가로 더 받아들여 처리
- 이 때 이 값이 너무 크면 스케줄링해야 할 스레드가 많아져서 스레드 풀이 비효율적으로 작동할 수도 있음
- 스레드 그룹의 모든 스레드가 일을 처리 중일 때!
- 새로운 작업 스레드 추가 VS 기존 작업 스레드가 처리를 완료할 때까지 기다릴지 여부를 판단
- 타이머 스레드 : 주기적으로 스레드 그룹의 상태를 체크해서 “스레드 풀 스톨 리미트” 시스템 변수에 정의된 밀리초만큼 작업 스레드가 지금 처리 중인 작업을 끝내지 못하면 새로운 스레드를 생성해서 스레드 그룹에 추가
- 이 때 전체 스레드의 개수는 “스레드 풀 맥스 스레드” 시스템 변수 이하
- 즉, 새로운 요청이 들어와도 thread_pool_stall_limit 시간동안 기다려야만 새로 들어온 요청을 처리할 수 있음
- 응답시간이 중요한 서비스라면 이 변수를 적절히 낮춰서 설정
- 그렇다고 0에 가까운 값으로 설정하면 그냥 스레드 풀을 사용하지 않는것이 낫다
4.1.10 트랜잭션 지원 메타데이터
- 8.0부터 테이블의 구조 정보나 저장된 프로그램의 코드 관련 정보를 모두 InnoDB의 테이블에 저장하도록 개선
- 시스템 테이블과 데이터 딕셔너리 정보를 모두 모아서 mysql DB에 저장하고 있음
- 그리고 mysql DB는 통째로 mysql.ibf라는 이름의 테이블 스페이스에 저장
- 이를 통해 비정상 종료가 되도 완전한 성공, 완전한 실패로 정리됨
-
