# Real MySQL 8.0 1권 스터디
- 대상: 8장 8.5~ 인덱스
- 일시: 2024년 9월 29일 일요일 오후 8시

# 참여자
- 알렉스
- 옐리

---

# 이해했는지 확인하기
- 한 줄로 설명하지 못하면 이해하지 못한 것으로 생각합시다.
- 이해했다고 착각한 것들 잡아봅시다.
- 이해하지 못한 부분은 스터디 종료 후 반드시 학습합시다.

## 8.5 전문 검색 인덱스
### 어근 분석을 위해 수행해야 하는 두 가지 작업
- 알렉스:불용어, 형태소 분석(어근 분석)
- 옐리: 불용어 처리를 하고 어근 분석을합니다. 불용어는 검색할 때 가치가 없는 단어를 필터링하는 것, 어근 분석은 단어의 어근을 분석해서 원형을 찾아가는 방법
### 어근 분석 외의 다른 알고리즘 이름은?
- (hint) n
- 옐리 :n-gram 알고리즘, 2-gram 두글자를 인덱스로 만드는 것
- 알렉스: n-gram 알고리즘, 단어들을 N개 만큼의 음절로 쪼개서 인덱스를 만듦. 2-gram => 2개의 글자로 쪼개서 인덱스로 만듦
### 전문 검색 인덱스를 사용하기 위한 조건 2가지
- 알렉스:
- 1. WHERE 조건절에서 전문 검색 인덱스를 위한 쿼리를 사용
- 2.
- 옐리:
- 1. Match -against를 사용해야 한다.
- 2. 검색할 컬럼에 전문 인덱스가 있어야 한다.

---

## 8.6 함수 기반 인덱스
### 함수 기반 인덱스를 사용하는 이유
- 옐리 : 변형해서 만들어진 값은 기존 인덱스에 포함되지 않기 때문
- 알렉스 : 기존 컬럼에 기반한 새로운 컬럼을 만들거나 할 때 기존 테이블에 새로운 인덱스가 필요. 함수를 이용한 인덱스는 실제 테이블 구조를 변경하지 않고 인덱스를 사용할 수 있기 때문

### 다음 중 '가상 컬럼 인덱스'와 '함수를 이용한 인덱스'를 구분하세요

#### 1번: ???

CREATE TABLE user (
    user_id BIGINT,
    first_name VARCHAR(10),
    last_name VARCHAR(10),
    PRIMARY KEY (user_id),
    INDEX ix_fullname((CONCAT(first_name, ' ', last_name)))
);

#### 2번: ???

CREATE TABLE user (
    user_id BIGINT,
    first_name VARCHAR(10),
    last_name VARCHAR(10),
    PRIMARY KEY (user_id)
);

ALTER TABLE user
ADD full_name VARCHAR(30) AS (CONCAT(first_name, ' ', last_name)) VIRTUAL,
ADD INDEX ix_fullname (full_name);

### 가상 컬럼 인덱스는 테이블의 구조를 변경하지 않는다.
- O vs X

### 함수를 이용한 인덱스는 테이블의 구조를 변경하지 않는다.
- O vs X

### 가상 컬럼 인덱스보다 함수를 이용한 인덱스가 성능이 더 빠르다
- O vs X
- 알렉스: O
- 옐리: O
---

## 8.7 멀티 밸류 인덱스
멀티 밸류 인덱스를 사용하려면 반드시 3가지 함수들을 이용해서 검색해야 합니다.

`member of`, `json_contains`, `json_overlabs` 세 함수의 차이에 대해서 알아보겠습니다.

### MEMBER OF 함수
- 특정 값이 JSON 배열에 포함되어 있는지를 확인합니다.

SELECT 3 MEMBER OF('[1, 2, 3, 4]');  -- 1 (참) 반환
SELECT 'a' MEMBER OF('["b", "c", "d"]');  -- 0 (거짓) 반환

### JSON_CONTAINS 함수
- 하나의 JSON 문서가 다른 JSON 문서에 포함되어 있는지 확인합니다. 즉, 특정 값 또는 구조가 첫 번째 JSON 문서에 존재하는지를 검사합니다.

-- 첫 번째 JSON 문서에 {"a": 1}이 포함되어 있는지 확인
SELECT JSON_CONTAINS('{"a": 1, "b": 2}', '{"a": 1}');  -- 결과: 1 (참)

-- 첫 번째 배열에 숫자 3이 포함되어 있는지 확인
SELECT JSON_CONTAINS('[1, 2, 3, 4]', '3');  -- 결과: 1 (참)

### JSON_OVERLABS 함수
- 두 JSON 값(배열 또는 객체) 간에 공통된 값이 있는지 확인할 때 사용합니다.

-- 두 JSON 객체에 공통된 키 "b"가 있으므로 결과는 참
SELECT JSON_OVERLAPS('{"a": 1, "b": 2}', '{"b": 3}');  -- 결과: 1 (참)

-- 두 배열에 숫자 3이 공통되므로 결과는 참
SELECT JSON_OVERLAPS('[1, 2, 3]', '[3, 4, 5]');  -- 결과: 1 (참)

## 8.8 클러스터링 인덱스
### 하나의 테이블에 여러 개의 클러스터링 인덱스를 가질 수 있다
- O vs X

### PK 값이 변경됐을 때 일어나는 일은?
- PK 값에 해당하는 레코드의 물리적인 저장 위치도 변경

### PK 를 생성하지 않으면 어떻게 되는지 설명해 보세요.
- (hint) 우선 순위 순서대로 말해보세요.
- 알렉스: 유니크 인덱스를 활용 => 만약 유니크 인덱스도 없으면 => 내부적으로 auto_increment 형식의 내부 인덱스 컬럼을 생성
- 옐리: 내부 칼럼은 사용자가 접근 못하니 auto_increment형식의 pk를 만드는 것이 권해짐

### 클러스터링 인덱스의 장점과 단점 1개씩 말해보세요
- 알렉스:
- 장점: 읽기 속도가 빠름
- 단점: 내부적으로 재정렬이 발생해서 쓰기 속도가 느려짐.
- 옐리:
- 장점: 읽기 속도가 빨라진다.
- 단점: 쓰기 속도가 그만큼 희생돼서 느려진다.

### 클러스터링 인덱스 키의 크기가 커지면 발생하는 문제를 말해보세요
- 세컨더리 인덱스가 5개 있다고 가정
- 프라이머리 키 크기가 10 바이트에서 50 바이트로 커진 상황을 가정
- 위 두 가정과 함께 100만개의 레코드를 저장한다고 가정
- 알렉스: InnoDB 특성과 관련. 세컨더리 인덱스의 끝 값은 PK. => PK 값이 커질수록 세컨더리 인덱스도 커진다. 공간 낭비가 심해진다.
- 옐리: 세컨더리 인덱스가 5개, 프라이머리 키가 5배 증가했기 때문에 처음에는 100만개 * 10바이트 * 5 = 5000만 바이트였음.(50MB) 5배 증가는 250MB가 될 것이다.

## 8.9 유니크 인덱스
### 유니크하지 않은 세컨더리 인덱스와의 읽기와 쓰기 성능을 비교해 보세요
- 읽기 성능: (옐리)-읽기 성능은 사실상 똑같다.
- (알렉스): 2가지 상황을 가정.
- 유니크하지 않다고해서 느리지 않다.
- 유니하지 않은 세컨더리 인덱스는 저장되는 데이터의 개수가 많아짐. 하지만 이것이 인덱스의 읽기 성능과는 별개다.
- 쓰기 성능: (옐리)-유니크한지 값을 체크해서 조금 더 느릴 수 있다.
- (알렉스): 중복되있는지 스캔하기 때문에 느리다.

## 8.10 외래키