• 스토리지 엔진 : 데이터가 디스크에서 저장되고 검색되는 방법을 구동하는 소프트웨어. mysql에서는 innoDB 권장.
  1. 논리적 아키텍쳐
    • (클라이언트) -> (연결/스레드 핸들링 -> 파서 옵티마이저 -> 옵티마이저) -> (스토리지 엔진(innoDB))
      (1) 최상위 계층 (클라이언트) : 네트워크 기반 클라이언트/서버 도구 or 서버에 필요한 연결 처리, 인증, 보안 등의 서비스의 포함.
      (2) 두 번째 계층 : 쿼리 파싱, 분석, 최적화 및 모든 기본 제공 함수를 포함하여 MYSQL에서 대부분의 지능적인 부분이 여기에 속함.
      (3) 세 번째 계층 : 스토리지 엔진이 포함됨. MYSQL에 저장된 모든 데이터를 저장하고 검색하는 역할 담당.

  2. 연결 관리 및 보안
    • 각 클라이언트 연결은 서버 프로세스 내에서 고유한 스레드를 가짐. 서버는 즉시 사용할 수 있는 스레드의 캐시 유지 관리 -> 새로운 연결마다 매번 스레드 생성/폐기 필요 x.

  3. 동시성 제어
    • shared lock, exclusive lock : oracle과 동일.
    • oracle은 행 수준 잠금만 사용하지만, mysql은 잠금 전략이 두가지.
      (1) 테이블 잠금 : 전체 테이블을 잠금. 가장 기본적인 잠금 전략이자 가장 낮은 오버헤드를 가진 전략. 유리 상황 : read local 테이블 잠금은 일부 유형의 동시 쓰기 작업을 허용. 쓰기 및 읽기 대기열은 읽기 대기열보다 전적으로 우선순위가 높은 쓰기 대기열과 별도로 관리.
      (2) 행 잠금 : 스프레드시트의 행만 잠그는 것과 같음. 가장 큰 동시성을 제공하고 오버헤드가 가장 큰 잠금 행태.

  4. 트랜잭션
    • oracle과 동일. acid 트랙잭션.
      (1) Deadlock : 현재 innodb가 deadlock 처리 방법 : exclusive lock이 가장 적은 트랜잭션으로 롤백.(교착상태 발생하면 트랜잭션의 일부 또는 전체를 롤백하지 않고는 교착상태 해제 안됨. -> so, 현재 트랜잭션 시스템은 application layer에서 처리하게 설계돼야함.)
      (2) 트랜잭션 로깅 : oracle과 동일하게 append 방식으로 로깅.
      (3) 트랜잭션에서 스토리지 엔진 혼합 : mysql은 서버 수준에서 트랜잭션 관리 x. -> innoDB가 트랜잭션 자체를 구현. => 단일 트랜잭션에서 서로 다른 엔진을 안정적으로 혼용 불가.(트랜잭션에서 트랜잭션 테이블과 비 트랜잭션 테이블을 혼영할 경우[innoDB] 모든 것이 순조로우면 트랜잭션이 제대로 작동. but, 롤백이 필요한 경우 비트랜잭션 테이블에 대한 변경 사항을 취소 불가능. => DB 일관성 파괴, 트랜잭션 지점 무의미) 결론 : 애플리케이션에서 스토리지 엔진 혼용 하지말자
      (4) 암시적 잠금과 명시적 잠금 : InnoDB는 2단계 잠금 프로토콜 사용. commit/rollback 될때까지 잠금 해제 x. but, innoDB는 SQL 표준에서 전혀 언급하지 않는 명시적 잠금도 지원. ex) select … for share / select … for update. 내기억에 오라클도 for update 지원.

  5. MVCC(multi version concurrency control)
    특정 시점에 존재했던 데이터의 snapshot을 사용하여 작동. = 트랜잭션은 실행 기간에 관계없이 데이터 일관되게 볼 수 있음.
    oracle 처럼 undo 사용하여 롤백후 이용.

  6. 복제
    한 노드가 사용하는 쓰기를 추가 노드에 배포하는 기본적인 방법. 소스 노드에 쓰려고 할 때 새 데이터를 보내는 복제 클라이언트로 로그인된 레플리카에 대한 스레드 있음.(토폴로지 트리)
    운영 환경에서 실행하는 데이터의 경우, 재해 복구 계획을 위해 복제를 사용하고 여러 위치에 분산되어 있는 3개 이상의 레플리카를 보유하는 것이 이상적.

  7. 데이터 파일 구조
    테이블 메타데이터 -> 테이블의 .ibd파일에 포함된 데이터 딕셔너리로 재설계(8.0기준).
    information_schema에만 의존하는 대신, 딕셔너리 오브젝트 캐시사용(oracle과 동일).

  8. InnoDB 엔진
    • 쿼리에서 터치한 행만 잠그는 것이 아니라 인덱스 구조의 공백도 잠가서 팬텀이 삽입되는 것을 방지.
    • db 테이블은 클러스터형 인덱스로 구성.
    • JSON 유형(5.7 이후) : json 문서의 자동 유효성 검사와 빠른 읽기 엑세스가 가능한 최적화된 스토리지.
    • 데이터 딕셔너리의 변화(8.0 이후) : 파일 기반 테이블 메타데이터 스토리지 제거 -> innoDB 테이블 스토리지를 사용하여 데이터 딕셔너리로 이동. -> 테이블 변경과 같은 작업에 모든 충돌 복구 트랜잭션의 이점을 제공.
    • Atomic DDL(8.0 이후) : 데이터 정의문이 완전히 완료되거나 완전히 롤백될 수 있음을 의미. DDL 관련 언두/리두 로그를 생성함으로써 가능.