[면접을 위한 CS 전공 지식 노트] 4장. 데이터베이스

Section 1. 데이터베이스의 기본

기본 개념

1. 데이터베이스: 일정한 규칙·규약을 통해 구조화되어 저장된 데이터 모음
2. DBMS: 데이터베이스 제어·관리·통합의 역할을 하는 시스템이다. 응용 프로그램들이 데이터베이스를 공유하고 사용할 수 있도록 만들어준다.
3. DBMS마다 정의된 쿼리 언어를 통해 CRUD 수행한다.

 

4.1.1 엔터티

• 엔터티: 여러 개의 속성(사람, 장소, 물건, 사건, 개념 등)을 지닌 명사를 의미한다. ex) 회원 - 이름, 아이디, 주소, 전화번호
  • 강한 엔터티
    • 다른 엔터티에 의존하지 않고도 식별 가능
    • ex) 학생(Student): 학번(Student ID)을 기본 키로 가지며, 다른 엔터티에 의존하지 않고 독립적으로 존재 가능
  • 약한 엔터티
    • 고유 식별자(Primary Key)가 없으며, 다른 엔터티(강한 엔터티)에 의존해서만 식별 가능한 엔터티
    • ex) 주문(Order)과 주문 상세(Order Detail):
      • Order Detail은 Order가 없으면 식별할 수 없음
      • Order Detail은 Order ID(외래 키)와 Item Number(보조 키)를 합쳐 식별 가능

4.1.2 릴레이션

• 릴레이션: 데이터베이스에서 데이터를 저장하는 구조적 형태이다. 관계형 데이터베이스에서는 테이블 형태로 표현하며, NoSQL 데이터베이스에서는 컬렉션이라고 한다.

특징	관계형 DB(RDB)	NoSQL
데이터 구조	릴레이션(테이블) 기반	문서, 키-값, 그래프 등 비정형 구조
스키마	고정된 스키마 (정형 데이터)	유연한 스키마 (반정형/비정형 데이터)
데이터 간 관계	키(Foreign Key)로 릴레이션 표현	명시적 관계 없음 (응용 프로그램 처리)
확장성	수직적 확장(Scaling Up)	수평적 확장(Scaling Out)
쿼리 언어	SQL	다양한 API 또는 쿼리 언어
사용 사례	금융, ERP, 전통적인 트랜잭션	소셜 네트워크, IoT, 빅데이터 분석
예시	MySQL(레코드-테이블-데이터베이스)	MongoDB(도큐먼트-컬렉션-데이터베이스)

 

4.1.3 속성

• 속성: 릴레이션에서 관리하는 구체적이며 고유한 이름을 갖는 정보이다. 엔터티(Entity) 또는 릴레이션(Relation)의 특성을 나타내는 데이터 항목(컬럼, 열)으로 쓰인다.
  • ex) 차의 속성
    • 차 넘버, 바퀴 수, 차 색깔, 차종 등

4.1.4 도메인

• 도메인: 각각의 속성들이 가질 수 있는 값의 집합이다.
  • ex) 속성 '성별'의 도메인: {남, 여}
   

속성과 도메인

 

4.1.5 필드와 레코드

필드와 레코드

 

• 엔터티: 회원
• 테이블: member
• 속성: 이름, 아이디, 주소 ..
• 필드: name, ID, address...
• 레코드: 테이블에 쌓이는 행(row) 단위의 데이터. 튜플이라고도 함.

 

필드 타입

• 숫자 타입

타입	용량(바이트)	최소값(부호 있음)	최소값(부호 없음)	최댓값(부호 있음)	최댓값(부호 없음)
TINYINT	1	-128	0	127	255
SMALLINT	2	-32768	0	32767	65535
MEDIUMINT	3	-8388608	0	8388607	16777215
INT	4	-2147483648	0	2147483647	4294967295
BIGINT	8	-9223372036854775808	0	9223372036854775807	18446744073709551615

 

• 날짜 타입

타입	설명	지원 범위	용량
DATE	날짜 부분은 있지만 시간 부분은 없는 값에 사용	1000-01-01 ~ 9999-12-31	3바이트
DATETIME	날짜 및 시간 부분을 모두 포함하는 값에 사용	1000-01-01 00:00:00 ~ 9999-12-31 23:59:59.	8바이트
TIMESTAMP	날짜 및 시간 부분을 모두 포함	1970-01-01 00:00:01 ~ 2038-01-19 03:14:07.	4바이트

 

• 문자 타입

타입	설명	예시
CHAR	고정 길이 문자열로, 길이를 미리 정의. 0~255 사이의 값 가능. 저장 시 정의된 길이로 고정됨.	CHAR(100) → 길이가 10인 데이터도 100바이트로 저장.
VARCHAR	가변 길이 문자열로, 길이는 0~65,535 사이. 입력 데이터에 따라 저장 용량 결정.	VARCHAR(10) → 길이가 10이면 10바이트만 사용.
TEXT	큰 텍스트 데이터를 저장. 게시판 본문 등 저장 시 사용.
BLOB	이미지, 동영상 등 큰 데이터 저장.  파일 경로를 VARCHAR로 저장 가능.	보통 서버에 파일을 올리고 파일에 관한 경로를 VARCHAR로 저장 (아마존의 이미지 호스팅 서비스인 S3 이용)
ENUM	ENUM(x-small, small, medium, large, x-large) 중 하나를 선택. 최대 65,535개의 요소 가능. ()공간적 이점이 있지만 수정에 따라 DB에 정의한 목록을 수정해야 하는 단점이 있다.
SET	여러 개의 데이터를 선택. 최대 64개의 요소 선택 가능. ()공간적 이점이 있지만 수정에 따라 DB에 정의한 목록을 수정해야 하는 단점이 있다.

 

 

4.1.6 관계

테이블 간에는 '관계'가 정의된다. 이러한 관계를 관계화살표로 나타낸다.

관계 화살표

 

관계	예시	설명
1:1		한 유저당 하나의 유저 이메일
1:N		한 유저당 여러 개의 상품, 혹은 0개의 상품을 장바구니에 넣을 수 있음
N:M		한 학생 당 여러 개의 강의 수강 가능. 한 강의 당 여러 명의 학생 수용 가능.

 

4.1.7 키

• 기본키(PK, Primary Key)
  • 특성
    • 유일성: 테이블 내에서 각 행을 고유하게 식별해야 함. 중복된 값이 존재할 수 없음.  ex) 학번
    • 최소성: 여러 속성을 조합하여 유일하게 식별할 수 있는 경우, 최소한의 조합만 선택해야 함
      • ex) 학번 만으로 구분 가능하면 기본키로 '학번'만을 채택. 불필요하게 학번+이름 조합을 기본키로 설정하면 안됨
  • 종류
    • 자연키: 현실 세계에서 이미 존재하는 고유한 속성을 기본키로 사용하는 것. ex) 주민등록번호, 학번, 자동차 번호판 등
    • 인조키: 데이터베이스에서 인위적으로 생성한 고유 값을 기본키로 사용하는 것. 일반적으로 숫자 값(시퀀스, 자동 증가)으로 만들어짐. ex) customer_Id 1, 2, 3처럼 자동 순차 증가
• 외래키(FK, Foreign Key)
  • 한 테이블의 속성이 다른 테이블의 기본키(Primary Key)를 참조하는 키
  • 테이블 간 관계를 연결하고 데이터의 참조 무결성(Referential Integrity)을 유지함
  • ex) 학생(학생ID, 이름) --- 수강(수강ID, 학생ID, 코스)
• 후보키(Candidate Key)
  • 테이블에서 유일하게 각 행(Row)을 식별할 수 있는 속성(또는 속성의 조합)으로 이루어진 키
  • 여러 개의 후보키 중 하나를 기본키로 선택함
• 대체키
  • 후보키 중에서 기본키로 선택되지 않은 키
• 슈퍼키
  • 테이블의 각 행(Row)을 고유하게 식별할 수 있는 속성(또는 속성의 집합).
  • 유일성은 만족하지만, 최소성은 만족하지 않을 수 있음
  • 학번(Student_ID) 하나만으로 학생을 유일하게 식별할 수 있다면, 학번 + 이름(Name)도 슈퍼키가 될 수 있음. 그러나 최소성을 만족하지 못하므로 기본키는 안 됨.

 

 

Section 2. ERD와 정규화 과정

ERD(Entity Relationship Diagram)란?

데이터베이스를 구축할 때 가장 기초적인 뼈대 역할을 하며, 릴레이션 간의 관계들을 정의한 것이다. 

ERD 예시

 

4.2.1 ERD의 중요성 

 

• 시스템 요구 사항을 기반으로 작성되며, ERD를 기반으로 데이터베이스를 구축하게 된다.
• 장점: 관계형 구조로 데이터 구성 시 유용하다.
• 단점: 비정형 데이터(텍스트, 이미지 ,오디오, 비디오 등)를 충분히 표현할 수 없다.

 

4.2.3 정규화 과정

 

정규화 과정이란?

릴레이션 간의 잘못된 종속 관계로 인해 데이터베이스 이상 현상이 일어나서 이를 해결하거나, 저장 공간을 효율적으로 사용하기 위해 릴레이션을 여러 개로 분리하는 과정이다. 정규화를 통해 데이터베이스 설계에서 데이터의 중복을 최소화하고, 데이터의 무결성을 유지하기 위해 테이블을 분리하고 관계를 설정한다. 

이를 통해 데이터를 효율적으로 저장하고 업데이터, 삭제, 삽입 시 일관성 있는 데이터를 유지할 수 있다. 

 

정규화 원칙

• 같은 의미의 릴레이션이지만 더 좋은 구조로 만들어야 함
• 자료의 중복성은 감소해야 함.
• 독립적인 관계는 별개의 릴레이션으로 표현해야 함.
• 각각의 릴레이션은 독립적인 표현이 가능해야 함.

주요 정규형

• 제1정규형
  • 각 셀(필드)에는 단일 값만 저장.
  • 반복 속성(중첩된 데이터)이 없어야 함. 
   

제1정규형

• 제2정규형
  • 부분 함수 종속 제거: 기본키의 일부에만 종속된 속성을 제거.
    • ex) 유저번호는 유저ID에만 종속되어 있으며, 수강명 과는 관련이 없음.
  • 기본키 전체에 종속된 속성만 남겨야 함.
    • ex) 유저 정보를 별도 테이블로 분리함. [유저번호 ,유저ID] / [유저ID, 수강명, 성취도]
   

제2정규형

• 제3정규형
  • 이행 함수 종속 제거: 기본키에 직접 종속되지 않은 속성을 제거.
    • ex) [학생ID, 학과ID, 학과명] <- 학과명은 학과ID를 통해 유도 가능
  • 기본키 외 다른 속성 간의 종속성이 없어야 함.
    • ex) [학생ID, 학과ID] 로만 테이블을 구성하면 됨. (다른 테이블: [학과ID, 학과명])

제3정규형: 종속관계가 PK-속성1 / 속성1-속성2 로 이루어짐

제 3정규형이 이뤄진 후에는 [PK-속성1] [속성1-속성2]로 나누어진다. 정규형 전에는 속성2가 PK에 직접 종속되지 않아 이행 함수 종속의 관계를 이루고 있었다. 

• 보이스-코드 정규형(BCNF: Boyce-Codd Normal Form)
  • 모든 결정자(X결정자 -> Y종속자)가 후보키가 되도록 설계.
    • 수강명 -> 강사: 수강명을 알면 해당하는 강사를 알 수 있음.
    • 학생학번 -> 강사: 학생학번을 알면 해당하는 강사를 알 수 있음.
  • 제3정규형을 만족했더라도, 후보키가 아닌 속성이 결정자가 될 경우 발생하는 특수한 이상현상(중복, 삽입/삭제 문제)을 해결.
    • 중복된 데이터
      • 코딩테스트-큰돌 여러 번 반복됨. 이러면 데이터 수정할 때 하나만 바뀌는 문제가 발생함.
    • 삽입 이상
      • 학번이 필요 없는 '롤 강좌 추가' 상황에서 학번이 NULL로 남아야 함.
    • => 학생학번-강사(학번으로 강사 고유하게 결정) / 수강명-강사(수강명으로 강사 고유하게 결정)로 테이블을 분리한다.

보이스/코드 정규형: 학번, 수강명이 각각 결정자의 역할을 함. 모두 후보키가 될 수 있게끔 테이블을 분리함.

보이스-코드 정규형이 이뤄진 후에는 결정자의 역할을 하는 속성1, 속성2가 모두 후보키(행에서 유일한 값)가 될 수 있다. 

 

Section 3. 트랜잭션과 무결성

4.3.1 트랜잭션

트랜잭션이란?

데이터베이스에서 논리적으로 하나의 작업 단위를 의미한다.
즉, 여러 작업(쿼리)이 하나의 작업처럼 묶여서 실행되고, 모든 작업이 성공하거나 모두 실패하는 방식으로 처리된다.

 

ACID 속성

1. 원자성(Atomicity)
   • 트랜잭션은 모두 성공하거나 모두 실패해야 함
   • 작업 중 하나라도 실패하면, 트랜잭션에 포함된 모든 작업이 취소(롤백)됨
   • ex) 은행 계좌 이체에서 출금이 성공했지만 입금이 실패하면 전체 작업이 취소되어야 함
2. 일관성(Consistency)
   • 트랜잭션 실행 전과 후의 데이터 상태가 일관성을 유지해야 함
   • 데이터베이스의 규칙(제약 조건)이 항상 만족되어야 함
   • ex) 계좌 잔액은 음수가 될 수 없다는 규칙이 깨지지 않아야 함. 50만원을 가진 사용자가 100만원을 출금하면 안됨.
3. 격리성(Isolation)
   • 동시에 여러 트랜잭션이 실행되더라도, 각각의 트랜잭션은 서로 독립적으로 실행됨
   • 트랜잭션이 완료되기 전에는 다른 트랜잭션이 해당 데이터를 볼 수 없음 
   • ex) 동시에 여러 사람이 쇼핑몰에서 같은 상품을 구매할 때, 재고 데이터가 올바르게 처리되어야 함
4. 지속성(Durability)
   • 트랜잭션이 성공적으로 완료되면, 그 결과는 영구적으로 저장됨
   • 데이터베이스에 장애가 발생해도 결과가 보존되어야 함
     • 이를 위해 데이터베이스는 체크섬(중복 검사의 한 형태. 오류 정정을 통해 자료의 무결성을 보호함), 저널링(트랜잭션 등 변경 사항에 대한 로그를 남기는 것.), 롤백 등의 기능을 제공함.
   • 예: 은행 이체가 완료된 후에는 시스템 오류가 발생하더라도 이체 내역이 사라지지 않아야 함

커밋과 롤백

• 커밋(Commit)
  • 트랜잭션에서 수행된 작업을 확정하고, 데이터를 영구적으로 저장하는 명령어이다.
  • "변경 내용을 확정" → 데이터베이스에 저장되고 되돌릴 수 없다.
• 롤백(Rollback)
  • 트랜잭션에서 수행된 작업을 취소하고, 데이터베이스를 트랜잭션 시작 이전 상태로 되돌리는 명령어이다.
  • "변경 내용을 취소" → 이전 상태로 복구한다.
  • ROLLBACK은 트랜잭션 중 오류가 발생했거나 작업을 중단하고 싶을 때 사용한다.
  • ACID 중 데이터의 일관성을 유지하기 위해 사용됩니다.
    • ex) 롤백은 A 계좌의 출금 작업을 취소하여 일관성 있는 상태(잔액이 맞는 상태)를 유지

 

트랜잭션 전파

하나의 트랜잭션이 실행될 때, 다른 트랜잭션과의 관계를 어떻게 처리할지 결정하는 규칙이다.

• 동작 방식
  • 트랜잭션 전파는 현재 실행 중인 트랜잭션이 있을 때 호출된 메서드(또는 작업)가 기존 트랜잭션에 참여할지, 새로운 트랜잭션을 시작할지를 정의한다.
  • 이를 통해 다중 트랜잭션 간의 일관성을 유지할 수 있다.
  • Spring 프레임워크에서는 @Transactional annotation을 통해 여러 쿼리 관련 코드들을 하나의 트랜잭션으로 처리한다.

 

# 격리성

격리성은 트랜잭션 수행 시 서로 끼어들지 못하는 것을 말한다. 복수의 병렬 트랜잭션은 서로 격리되어 마치 순차적으로 실행되는 것처럼 작동되어야 한다. 

 

그럼 그냥 순차적으로 진행하면 쉽겠다고 생각할 수 있지만 성능이 나쁘다. 

 

➡️ 따라서 여러 개의 격리 수준으로 나누어 격리성을 보장한다.

 

여러 개의 격리 수준

• 격리 수준

격리 수준	설명	발생할 수 있는 문제
SERIALIZABLE	가장 강력한 격리 수준으로, 트랜잭션이 직렬화된 순서대로 실행. 동시성은 가장 낮음.	다수의 트랜잭션이 동시에 같은 데이터를 읽거나 수정하려고 하면 교착상태가 발생함. 가장 성능이 떨어지는 격리 수준임.
REPEATABLE_READ	팬텀 리드는 방지하지만, 반복 불가능한 읽기는 발생하지 않음.	팬텀 리드
READ_COMMITTED	커밋 완료된 데이터에 대해서만 조회를 허용함. 가장 많이 사용되는 격리 수준임.	반복 불가능한 읽기
READ_UNCOMMITTED	다른 트랜잭션의 커밋되지 않은 데이터를 읽을 수 있으므로 가장 빠름. 데이터 무결성에 취약.	팬텀 리드, 반복 불가능한 읽기, 더티 리드

 

 

• 격리 수준에 따라 발생하는 현상

 

현상	설명	예시
팬텀 리드 (Phantom Read)	한 트랜잭션에서 동일한 조건으로 데이터를 두 번 조회할 때, 처음에는 없었던 데이터가 두 번째 조회 시 나타나는 현상.	A 사용자가 age >= 5000 조건으로 데이터를 조회한다. B 사용자가 새로운 데이터를 추가하여 A가 다시 조회하면 추가된 데이터가 나타난다.
반복 가능하지 않은 조회 (Non-Repeatable Read)	한 트랜잭션에서 동일한 데이터를 두 번 조회했을 때, 첫 번째 조회와 두 번째 조회의 결과가 다른 경우.	A 사용자가 특정 행을 조회한 후, B 사용자가 그 데이터를 수정하거나 삭제하여 A가 다시 조회했을 때 데이터가 변경되거나 삭제됨.
더티 리드 (Dirty Read)	하나의 트랜잭션이 다른 트랜잭션의커밋되지 않은(임시 상태)데이터를 읽는 상황. 해당 트랜잭션이 롤백되면, 이미 읽은 데이터는 잘못된(Dirty) 데이터가 되어 데이터의 일관성이 깨질 수 있음.	B 사용자가 데이터를 수정했지만 트랜잭션을 커밋하지 않은 상태에서 A 사용자가 그 데이터를 읽은 경우. 이후 B가 롤백하면 A가 잘못된 데이터를 읽음.

 

 

Section 4. 데이터베이스의 종류

4.4.1 관계형 데이터베이스(RDBMS)

 

유형	DBMS	특징	주요 사용 사례
RDBMS	MySQL	- 관계형 데이터베이스로, 데이터를 테이블 형태로 저장. - SQL 사용. - 높은 안정성과 성능, 트랜잭션 처리 지원. - ACID 속성 준수. - 다양한 커넥터를 통해 다수의 언어와 통합 가능. - InnoDB, MyISAM 등 스토리지 엔진 제공.	메타데이터 관리, 금융 시스템, 소셜 네트워크
	PostgreSQL	- 고급 SQL 기능과 JSON 데이터 처리 지원. - ACID 속성 준수 및 복잡한 데이터 모델링에 적합. - VACUUM 기능으로 디스크 공간 회수. - 확장된 기능과 유연한 데이터 타입 지원.	데이터 분석, 대규모 데이터 처리 시스템
NoSQL	MongoDB	- 문서 지향 데이터베이스(JSON 기반). - 스키마리스(Schema-less)로 유연한 구조 지원. - 확장성 및 성능이 뛰어나 빅데이터와 비정형 데이터 처리에 적합. - ObjectID를 통해 데이터 고유성 보장.	IoT, 빅데이터 분석, 로그 관리
	Redis	- 키-값 기반의 인메모리 데이터베이스. - 매우 빠른 성능. - 세션 관리, 실시간 데이터 처리 및 캐싱 용도로 사용. - pub/sub 기능 지원.	실시간 채팅 시스템, 캐싱, 순위 관리 서비스

 

 

 

Section 5. 인덱스

4.5.1 인덱스의 필요성

인덱스란? 

데이터를 빠르게 찾을 수 있는 하나의 장치이다. 책의 색인처럼, 데이터베이스에서 검색 속도를 높이기 위해 사용한다.

 

4.5.3 B-트리

B-트리 예제

B-트리란?

B-트리는 데이터베이스와 파일 시스템에서 대용량 데이터를 효율적으로 관리하기 위해 사용되는 균형 트리 자료구조이다.
특히, 데이터가 디스크에 저장되는 환경에서 검색, 삽입, 삭제와 같은 작업을 효율적으로 처리할 수 있도록 설계되었다.

 

• B-트리 특징
  • 노드의 구성:
    • 각 노드는 키(key)와 포인터(pointer)로 구성된다.
    • 루트 노드는 트리의 최상단 노드이고, 리프 노드는 트리의 최하단 노드이다.
  • 정렬된 데이터:
    • B-트리의 노드 안에 있는 키들은 항상 오름차순으로 정렬되어 있다.
  • 균형 유지:
    • 모든 리프 노드는 같은 레벨에 있어 트리가 항상 균형을 유지한다.
    • 삽입과 삭제 과정에서도 트리의 균형이 유지되도록 설계되었다.
  • 다중 분기:
    • 하나의 노드가 여러 개의 자식을 가질 수 있다. (이진 트리와 다름)
    • 각 노드의 자식 수는 트리의 차수(Order)에 따라 달라진다.
  • 효율적인 검색:
    • B-트리는 키를 검색할 때, 각 노드의 키를 순차적으로 검색한 뒤 다음 자식 노드로 이동한다.
    • 노드가 디스크 블록 단위로 저장되므로, 디스크 접근 횟수를 줄이는 데 유리하다.
• B+ 트리와의 비교

특징	B-트리	B+트리
데이터 크기	상대적으로 작은 데이터	대규모 데이터 처리
검색	랜덤 검색 위주	순차 검색과 범위 검색에 유리
메모리 사용	저장 공간을 더 효율적으로 사용	더 많은 공간이 필요할 수 있음
쓰기 작업	쓰기 작업이 빠름	쓰기 작업이 느릴 수 있음
구조의 복잡성	간단함	더 복잡함

 

4.5.3 인덱스 만드는 방법

• MySQL
  • 클러스터형 인덱스
    • 테이블당 하나를 설정할 수 있음
    • PK 옵션으로 기본키를 만들면 클러스터형 인덱스 생성이 가능함
    • unique not null 옵션을 붙이면 클러스터형 인덱스로 만들 수 있음
  • 세컨더리 인덱스
    • create index... 명령어 기반으로 만들 수 있음.
    • 하나의 인덱스만 생성할 경우에 사용하는 것은 옳지 않음(클러스터형 권고)

 

• MongoDB
  • 도큐먼트를 만들면 자동으로 ObjectID가 형성되고, 해당 키가 기본키로 설정됨
  • 세컨더리키도 부가적으로 설정해서 기본키와 세컨더리키를 같이 쓰는 복합 인덱스를 설정할 수 있음

 

4.5.4 인덱스 최적화 기법

1. 인덱스는 비용이다
   • 읽기 비용이 든다: 인덱스 리스트, 그 다음 컬렉션 순으로 두 번 탐색함
   • 수정 비용이 든다: 인덱스 수정, B-트리 높이 균형 있게 조절, 데이터를 효율적으로 조회할 수 있도록 분산시킴
   • 따라서 인덱스를 무작정 다 설정하는 것이 답은 아님. 또한, 컬렉션에서 가져와야 하는 양이 많을수록 인덱스를 사용하는 것은 비효율적임.
2. 항상 테스팅하라
   • 서비스마다 객체의 깊이, 테이블의 양 등이 다르기 때문에 최적화 기법은 달라진다. 따라서 테스팅이 중요하다.
   • explain() 함수를 사용하여 인덱스를 만들고 쿼리를 보낸 이후에 테스팅을 하며 소요되는 시간을 최소화해야 한다.
3. 복합 인덱스는 같음 > 정렬 > 다중 값 > 카디널리티 순이다
   1. 같음을 비교하는 쿼리(== 이나 equal)가 있다면 제일 먼저 인덱스로 설정한다.
   2. 정렬에 쓰는 필드하면 그 다음 인덱스로 설정한다.
   3. 다중 값을 출력하는 필드(쿼리가 >, < 이거나 많은 출력을 해야 하는 쿼리)라면 나중에 인덱스를 설정한다.
   4. 카디널리티(유니크한 값의 정도)가 높은 순서를 기반으로 인덱스를 생성한다.

 

4.6 조인의 종류

조인이란?

두 개 이상의 테이블을 묶어서 하나의 결과물을 만드는 것을 말한다. MySQL에서는 JOIN, MongoDB에서는 lookup이라는 쿼리로 이를 처리한다. 참고로 MongoDB는 조인 연산(look up)에 대해 관계형 데이터베이스보다 성능이 떨어진다고 여러 벤치마크 테스트에서 알려져 있습니다.

 

• 조인의 종류

inner join / left outer join / right outer join / full outer join

 

Section 7. 조인의 원리

조인 방식	설명	장점	단점	적합한 상황
중첩 루프 조인	- 외부 테이블의 각 행에 대해 내부 테이블의 모든 행을 비교 - 가장 기본적인 조인 방식	- 단순하고 구현이 쉬움 - 작은 데이터셋에서 효율적임	- 데이터 크기가 클수록 성능 저하 - 비교 횟수가 많음	- 작은 데이터셋 - 인덱스를 활용할 수 있는 경우
정렬 병합 조인	- 두 테이블이 정렬된 상태에서 병합하여 조인 - 양쪽 데이터를 정렬한 후, 포인터를 이동하며 비교	- 대규모 데이터에서도 효율적 - 정렬된 데이터에서 빠름	- 두 테이블 모두 정렬하는데 추가적 비용이 듦 - 정렬되지 않은 경우 비효율적	- 양쪽 테이블이 정렬된 상태 - 정렬 비용이 적은 경우
해시 조인	- 한 쪽 테이블에 대해 해시 테이블을 생성하고, 다른 테이블의 데이터를 이 해시 테이블과 매칭함 - 주로 동등 조인에 사용	- 대규모 데이터에서 효율적 - 정렬 불필요 - 동등 조인에서 성능 우수	- 메모리 사용량 많음 - 해시 충돌 발생 시 성능 저하	- 대규모 데이터 - 동등 조인이 필요한 경우  - 메모리 자원이 충분한 경우

 

• MySQL의 해시 조인 단계
  • 빌드 단계
    • 입력 테이블 중 하나를 기반으로 메모리 내 해시 테이블을 빌드하는 단계이다. 이때 조인에 사용되는 필드가 해시 테이블의 키로 사용된다. 
  • 프로브 단계
    • 레코드를 읽기 시작한다. 각 레코드를 찾아서 결과값으을 결반환한다.