MySQL 성능 최적화 > 01. MySQL 아키텍처

MySQL 논리적 아키텍처

🫥 Mysql 서버 = MySQL엔진 + 스토리지 엔진

첫번째 층 네트워크 기반 클라이언트 서버 연결 처리, 인증 보안 ( MySQL에 한정적인 것은 아님)

두번째 층 MySQL의 두뇌 쿼리 파싱 분석 등…

세번째 층 스토리지 엔진 저장된 데이터를 검색하고 저장하는 역할 서버는 스토리지 API로 소통하여 엔진 별 차이점을 못느낀다.

• 연결 관리와 보안 서버 프로세스는 클라이언트 연결별로 스레드가 있다. 서버는 개별 쿼리에 대해 각 클라이언트가 권한이 있는지 여부 확인
  
• 최적화와 실행 옵티마이저는 서버가 쿼리를 어떻게 최적화시키는지에 영향을 미침 , 쿼리 캐시 등 → 개발자는 옵티마이저가 더 나은 결정을 하도록 쿼리 작성

  parse tree
  - SQL의 기본 문법 오류를 체크하며 쿼리를 의미있는 단위의 토큰으로 쪼갠 후 트리 형태 구조로 변경

• 동시성 제어

  1. 읽기/쓰기 잠금( 공유잠금, 배타적잠금) : 쓰기 잠금의 경우 클라이언트가 변경하는 동안 다른 클라이언트가 읽지 못하도록 막는다. 그러나 읽기는 여러 클라이언트가 서로 간섭없이 동일한 자원 동시에 읽기 가능

  2. 잠금 세분성

     1. 테이블 잠금 : 오버헤드가 가장 적고 큐에서 쓰기 잠금은 선행이 가능하다
     2. 레코드 락 : 최대의동시성과 오버헤드 스토리지 엔진 내에서 구현

  3. 트랙잭션 : 작업 단위로 취급 (ACID 원자성, 일관성, 독립성/격리 ,영속성)

  4. 격리 수준 : 낮은 격리 수준은 보통 고도의 동시성과 낮은 오버헤드

     1. READ UNCOMMITTED : 커밋이 되지 않은 트랜잭션의 결과를 볼 수 있다. dirty read라고 불림
     2. READ COMMITTED : 커밋이 되기 전까지는 다른 트랜잭션에서보이지 않음
     3. REPEATABLE READ : 트랜잭션이 읽는 모든 레코드가 같은 트랜잭션 내에서 뒤에 일어난 읽기가 모두 동일하게 보이도록 보장 그러나 팬텀 리드 가 생길 수 있음
     4. SERIALIZABLE : 트랜잭션이 순차적으로 실행

     격리 수준 제어는 무조건 사이드 이펙트가 생김 (동시성 제어 kafka 사용 러닝 커브가 있음 queue) sqs사용 softlock 옵티미스락

     상태값은 순차적으로

• 데드락 트랜잭션이 자원에 대한 락을 서로 다른 순서로 얻으려고 할 때 발생 InnoDB는 데드락이 발생하면 배타적 레코드가 가장 적게 가진 트랜잭션을 롤백하는 방식!
  
• 트랜잭션 로깅 스토리지 엔진은 변경이 일어날 때마다 디스크의 테이블을 갱신하는 대신 메모리에 있는 데이터 사본만 변경하여 매우 빠르고 이후 디스크 안에 있는 영속적인 트랜잭션 로그에 변경 내용을 기록! 그 후에 DB는 디스크 안에 테이블을 갱신한다. WAL ( Write-Ahead Loggin
  

MySQL의 트랜잭션

• AUTOCOMMIT : 트랜잭션이 명시적으로 시작되지 않는한, 각 쿼리는 개별 트랜잭션으로 처리된다. MyISAM은 항상 AUTOCOMMIT이여서 변경되어도 영향 없음

MVCC(다중 버전 동시성 제어)

트랜잭션이 시작할 때 스냅샷을 만들고 해당 트랜잭션은 그것을 가지고 동작!