본문 바로가기

분류 전체보기89

옵티마이저 Optimizer 1. 쿼리 실행 절차① SQL Parser: 요청된 SQL문장을 MySQL 서버가 이해할 수 있는 수준으로 분리하고 문법상 문제가 없는지 확인한다. ② Optimiser: SQL 파스 트리를 확인하면서 어떤 테이블에서 어떤 인덱스를 이용해 테이블을 읽을지 실행계획을 세운다.③ 실행계획대로 스토리지 엔진으로부터 데이터를 가져온다. 2. 옵티마이저 역할불필요한 조건 제거 및 복잡한 연산의 단순화여러 테이블의 조인이 있는 경우 어떤 순서로 테이블을 읽을지 결정각 테이블에 사용된 조건과 인덱스 통계 정보를 이용해 사용할 인덱스 결정가져온 레코드들을 임시 테이블에 넣고 다시 한번 가공해야 하는지 결정 3. 비용 기반 최적화 옵티마이저옵티마이저는 DBMS 두뇌와 같은 역할을 하며 MySQL의 옵티마이저는 비용 기반.. 2025. 3. 6.
인덱스 Index - (6) :클러스터링 인덱스 책에 비유하자면클러스터링 인덱스는 페이지를 이미 알기 때문에 바로 그 페이지를 펴는 것세컨더리 인덱스는 목차에서 찾고자 하는 내용의 페이지를 찾고 그 페이지로 이동하는 것테이블 스캔은 처음부터 한 장씩 넘기면서 내용을 찾는 것이다. 1. 클러스터링 인덱스클러스터링이란 여러 개를 하나로 묶는다는 의미로 주로 사용된다. MySQL에서 클러스터링 인덱스는 InnoDB 스토리지 엔진에서만 지원하며 PRIMARY KEY(이하 PK)를 기준으로 여러 레코드를 묶어서 저장하는 형태로 구현된다. 이는 비슷한 값들을 동시에 조회하는 경우가 많다는 점에서 착안한 것이다. 여기서 중요한 점은 PK 값에 의해 레코드의 물리적인 저장 위치가 결정된다는 것이다. 또한 PK 값이 변경된다면 그 레코드의 물리적인 저장 위치가 바뀌.. 2025. 3. 6.
인덱스 Index - (5) 1. 다중 컬럼 (Multi-column) 인덱스두 개 이상의 컬럼으로 구성된 인덱스를 다중 컬럼 인덱스(또는 복합 칼럼 인덱스)라고 한다. 그림(1)에서는 편의상 루트 노드는 생략했으나 실제로 데이터 레코드 건수가 작은 경우에는 브랜치 노드가 없는 경우도 있을 수 있다. 하지만 루트 노드와 리프 노드는 항상 존재한다. 다중 칼럼 인덱스에서 중요한 점은 두 번째 컬럼은 첫 번째 컬럼에 의존해서 정렬돼 있다는 것이다. 즉 두번째 컬럼의 정렬은 첫 번째 컬럼이 똑같은 값일 때 의미가 있다는 것이다. 2. 인덱스의 정렬MySQL 8.0 버전부터는 아래와 같이 정렬 순서를 혼합한 인덱스를 생성할 수 있다. MySQL 5.7에서는 상위 버전과의 호환성을 위해 문법상으로만 제공을 하였고 실제로는 오름차순 정렬만으로.. 2025. 3. 5.
인덱스 Index - (4) :B-Tree 인덱스를 통한 데이터 읽기 1. 인덱스 레인지 스캔인덱스를 통해 레코드를 한 건만 읽는 경우와 한 건 이상을 읽는 경우는 각각 다른 이름으로 구분하지만, 여기서는 '인덱스 레인지 스캔'으로 통일한다. 자세한 내용은 '실행 계획'에서 다루도록 하겠다. -- SELECT (1)SELECT first_name FROM employees WHERE first_name BETWEEN 'Ebbe' AND 'Gad';인덱스 레인지 스캔은 검색해야 할 인덱스의 범위가 결정됐을 때 사용하는 방식이다. 그림(1) 화살표에서도 알 수 있듯이 루트 노드에서부터 비교를 시작해 브랜치 노드를 거쳐 최종적으로 리프 노드까지 찾아 들어가야만 비로소 필요한 레코드의 시작 지점 (리프 노드 페이지 (5) 인덱스 키 Ebbe)을 찾을 수 있다. 일단 시작지점을 .. 2025. 3. 5.
인덱스 Index - (3) 1. 인덱스 키 값의 크기InnoDB 스토리지 엔진은 디스크에 데이터를 저장하는 가장 기본 단위를 페이지(Page) 또는 블록(Block)이라고 하며 디스크 I/O 최소 작업 단위가 된다. 또한 페이지는 InnoDB 스토리지 엔진의 버퍼 풀에서 데이터를 버퍼링하는 기본 단위이기도 하다. 인덱스도 결국은 페이지 단위로 관리되며 루트, 브랜치, 리프 노드를 구분한 기준이 바로 페이지 단위다. 일반적으로 DBMS의 B-Tree는 자식 노드의 개수가 가변적인 구조다. MySQL의 B-Tree는 인덱스의 페이지 크기와 키 값의 크기에 따라 결정된다. MySQL 8.0 버전에서는 InnoDB 스토리지 엔진의 페이지 크기를 innodb_page_size 시스템 변수를 이용해 4KB, 8KB, 16KB, 32KB, 6.. 2025. 3. 5.
인덱스 Index - (2) 1. B-Tree 인덱스 키 추가새로운 키 값이 B-Tree에 저장될 때 테이블의 스토리지 엔진에 따라 새로운 키 값이 즉시 인덱스에 저장될 수도 있고 딜레이 될 수도 있다. B-Tree에 저장될 때는 저장될 키 값을 이용해 B-Tree상의 적절한 위치를 검색해야 한다. 저장될 위치가 결정되면 레코드의 키 값과 대상 레코드의 주소 정보를 B-Tree의 리프 노드에 저장한다. 리프 노드가 꽉 차면 리프 노드가 분리되어야 하는데 이것은 상위 브랜치 노드까지 처리의 범위가 넓어지기 때문에 B-Tree는 상대적으로 쓰기 작업(새로운 키를 추가하는 작업)에 비용이 많이 드는 것으로 알려져 있다. 인덱스 추가로 인해 INSERT, UPDATE 문장이 어느정도 비용이 발생하는지는 테이블의 컬럼 수, 컬럼의 크기, 인.. 2025. 3. 4.

티스토리툴바