본문 바로가기

전체 글

 (164)
[MySQL 스터디 11주차] 실습 실습 1 ) 복합 인덱스 설계와 filesort 제거 1. salary 에만 index를 추가한 경우 👉 실행계획 분석 • key : idx_salary - 새로 추가한 salary 인덱스를 탔음 • key_len : 4 - salary 가 int(4byte)였으므로 salary를 인덱스로 탔음 • rows : 50 - 50개의 결과를 내놓기 위해 50개의 행을 건들였음 • filtered: 1.00 - 인덱스로 거른 50개 중에 1%를 답으로 내었음 (??) - 인덱스를 타긴탔는데 타서 50개 중에 5개만 실제 정답에 포함시키고 나머지는 인덱스를 암것도 안걸었을 때처럼 가져왔다는건가...?? • Extra : Using where; Backward index scan ..
[MySQL 스터디 10주차] 실행 계획 10.1 통계 정보 • MySQL 서버는 5.7까지 테이블과 인덱스에 대한 개괄적인 정보를 가지고 실행 계획 수립했다. • MySQL 8.0 부터 인덱스되지 않은 칼럼들에 대해서도 데이터 분포도를 수집해서 저장하는 히스토그램 정보가 도입되었다. 10.1.1 테이블 및 인덱스 통계 정보 • 비용 기반 최적화에서 가장 중요한 것 : 통계 정보 예) 1억 건의 레코드가 저장된 테이블의 통계 정보가 레코드가 10건 미만으로 되어있다면 옵티마이저는 인덱스 레인지 스캔을 사용하지 않고, 풀 레인지 스캔을 사용할 수 있다. 10.1.1.1 MySQL 서버의 통계 정보 • MySQL 5.5 까지는 테이블 통계 정보가 메모리에서만 관리 되었다. -> 서버 재 시작 시 통계 정보 모두 사라짐 • MySQL 5..
[MySQL 스터디 9주차] 고급 최적화 9.3 고급최적화 • MySQL서버의 옵티마이저가 실행 계획 수립할 때 통계 정보 + 옵티마이저 옵션 결합하여 실행 계획 수립한다. • 옵티마이저 옵션 : 조인 관련 옵티마이저 옵션, 옵티마이저 스위치9.3.1 옵티마이저 스위치 옵션 • 각각 default, on, off 중에서 선택 가능9.3.1.1 MRR과 배치 키 인덱스 👉 nested loop join • 드라이빙 테이블의 레코드를 한 건 읽어서 드리븐 테이블의 일치하는 레코드를 찾아서 조인을 수행 • 드라이빙 테이블의 레코드 건별로 드리븐 테이블의 레코드를 찾으면, 레코드를 찾고 읽는 스토리지 엔진에서는 최적화 수행 불가능 👉 MRR : Multi Range Read-> MySQL 서버는 조인 대상 테이블 중 하나..
[MySQL 스터디 8주차] 옵티마이저와 힌트 • MySQL 서버로 요청된 쿼리의 결과는 동일하지만, 내부적으로 그 결과를 만들어내는 방법(실행 계획)은 다양하다. • MySQL에서는 EXPLAIN 을 통해서 쿼리의 실행 계획을 확인할 수 있다. 9.1 개요 • 쿼리의 실행계획을 만들어내는 부분은 옵티마이저이다.9.1.1 쿼리 실행 절차👉 MySQL에서 쿼리가 실행되는 과정 1. SQL 파싱 • SQL 문장을 잘게 쪼개서 MySQL 서버가 이해할 수 있는 수준으로 분리 (Parse Tree) 한다. • "SQL 파서" 라는 모듈로 처리 • SQL 문장이 문법적으로 잘못되었다면 이 부분에서 걸러진다.2. 최적화 및 실행 계획 수립 • SQL의 파싱 정보(Parse Tree)를 확인하며 어떤 테이블부터 읽고, 어떤 인덱스를 이용해 테이블..
[MySQL 스터디 7주차] 인덱스 8.4 R-Tree 인덱스👉 공간 인덱스(spatial index) : R-Tree 인덱스 알고리즘을 이용해 2차원의 데이터를 인덱싱하고 검색하는 목적의 인덱스 • B-Tree와 내부 메커니즘은 흡사하나 B-Tree 는 1차원, R-Tree 는 2차원의 공간 개념 값이다. 8.4.1 구조 및 특성 • 공간 정보의 저장 및 검색을 위해 여러 가지 기하학적 도형 정보 관리할 수 있는 데이터 타입 제공 - point, line, polygon, geometry(point, line, polygon을 모두 저장할 수 있는 슈퍼 타입) • MBR (Minimum Bounding Rectangle) : 각 도형을 제일 안쪽에서 둘러싼 점선 상자에 따라 가장 큰 최상위 MBR은 R-Tree의 루트에, 차상위..
[MySQL 스터디 6주차] B-Tree 인덱스 사용에 영향을 미치는 요소 8.3.3. B-Tree 인덱스 사용에 영향을 미치는 요소8.3.3.1 인덱스 키 값의 크기👉 페이지 • InnoDB 에서 디스크에 데이터를 저장하는 가장 기본 단위 • 디스크의 모든 읽기 및 쓰기 작업의 최소 작업 단위 • InnoDB 버퍼 풀에서 데이터를 버퍼링 하는 기본 단위 • 인덱스도 페이지 단위로 관리되며, 루트, 브랜치, 리프 노드를 구분하는 기준 👉 MySQL에서 B-Tree 는 이진 트리를 사용하지 않는다. 그러면 자식 노드를 몇 개까지 가질까? • 인덱스의 페이지 크기와 키 값의 크기에 따라 결정된다. • 가정1 - 인덱스 1개의 크기 : 16byte - 자식노드 주소 크기 : 12byte - 인덱스 페이지 크기 : 16KB - 16*1024(=1KB..
[MySQL 스터디 5주차] 데이터 압축, 인덱스 5주차 - 4월 20일 월요일6. 데이터 압축8.1 ~ 8.2 인덱스 6. 데이터 압축- 디스크에 저장된 데이터 파일의 크기는 쿼리 처리 성능, 백업 및 복구 시간과 연관성이 있음- 데이터 압축 기능을 제공- MySQL 압축 방식 : 테이블 압축, 페이지 압축 6.1 페이지 압축- MySQL 서버가 디스크에 저장하는 시점에 데이터 페이지가 압축되어 저장, MySQL서버가 디스크에서 데이터 페이지를 읽어올 때 압축 해제1. 16KB 페이지를 압축 (압축 결과는 7KB로 가정)2. MySQL 서버는 디스크에 압축된 결과 7KB 기록 (압축된 데이터 7KB, 빈 데이터 9KB 기록)3. 디스크에 데이터 기록 후 9KB에 대해 펀치 홀 생성4. 파일 시스템은 7KB 남기고 9KB는 다시 운영체제에 반납- ..
[MySQL 스터디 4주차] 트랜잭션과 잠금 - InnoDB 잠금, 격리수준 4주차 - 4월 13일 월요일5.3 InnoDB 스토리지 엔진 잠금5.4 MySQL의 격리 수준 ---내용 요약---👉 InnoDB 스토리지 엔진 잠금1. 레코드 락2. 갭 락3. 넥스트 키 락4. 자동 증가 락-> InnoDB는 넥스트 키 락(레코드 락 + 갭 락)을 주로 사용하고, 상황에 따라 (더 좁게) 레코드 락 또는 갭 락을 사용하여 최적화로 사용 👉 MySQL의 격리 수준1. READ UNCOMMITTED (= DIRTY READ)2. READ COMMITTED3. REPEATABLE READ - InnoDB 스토리지 엔진에서 기본적으로 사용되는 격리 수준4. SERIALIZABLE---스터디한 내용---5.3 InnoDB 스토리지 엔진 잠금- MySQL에서 제공하는 잠금과 별개로 스토리지..

티스토리툴바