(1) 6장. 데이터베이스와 SQL

(1) 6장. 데이터베이스와 SQL

28~30강 인덱스와 뷰

---

인덱스 (색인 or 목차) == 정렬

: 테이블에 대한 동작 속도를 높여주는 자료구조

• 고속의 검색(select, where) 동작

• 레코드 접근 관련 효율적인 순서 매김 동작

• 테이블 내의 1개 또는 여러 개의 컬럼을 이용하요 생성

• 카디널리티가 높은순 → 낮은순으로 구성하는 것이 성능에 더 도움

  

• 인덱스는 테이블에 의존하는 객체로 테이블을 삭제하면 인덱스도 함께 삭제된다

  • 오라클 / DB2 ; 인덱스는 스키마 객체 → 스키마 내에 이름이 중복되지 않도록 관리
  • SQL Server / MySQL ; 인덱스는 테이블 내 객체 → 테이블 내에 이름이 중복되지 않도록 관리

• 인덱스에 쓰이는 대표적 검색 알고리즘은 Binary search (이진 트리에는 중복하는 값을 등록할 수 없음 → 유일성을 지님)

  

• PK 컬럼에는 자동적으로 인덱스가 생성되므로, NOT NULL UNIQUE 제약 조건이 걸림

---

클러스터링 인덱스

• 유의 사항
  • 클러스터형 인덱스는 인덱스 자체의 리프 페이지가 곧 데이터의 페이지로 인덱스 자체에 데이터가 포함되어 있어 검색 성능이 좋지만, 테이블당 한 개만 생성이 가능하다. 다만 데이터의 입력/수정/삭제는 느리므로 어느 컬럼에 클러스터형 인덱스를 생성하느냐에 따라 성능이 좌지우지될 수 있다.
  • 비 클러스터형 인덱스는 별도의 페이지에 구성되는 인덱스로, 데이터가 위치하는 포인터를 저장한다. 따라서 클러스터형 인덱스보다 검색 속도는 느리지만, 데이터의 입력/수정/삭제는 더 빠르다. 또한 여러 개 생성이 가능하지만, 남용할 경우 오히려 시스템 성능을 떨어뜨리는 결과를 가져온다

---

EXPLAIN 구절

• DESCRIBE 동의어로 MySQL이 SELECT 명령문 실행 시 어떤 방법으로 진행되는지에 대한 정보를 얻기 위한 수단

• select_type

  

• type (join 타입)

  

• possible_keys

  • 쿼리 처리를 위해 MySQL이 고려한 인덱스 후보

    

• key

  • possible_keys 중에서 실제로 사용한 인덱스(키)

• key_len

  • MySQL이 사용하려고 결정한 인덱스(키)의 길이
  • 이 값으로 MySQL이 복수 컬럼 key 중 얼마나 많은 부분을 사용하는지 알 수 있음
  • key 칼럼이 NULL이라면, 이 값도 NULL

• rows

  • 쿼리를 실행하기 위해 조사해야 하는 열의 숫자

• filtered

  • rows * filtered / 100 = 전 테이블과 조인된 레코드 수
  • 조건에 따라 필터 되어 취득하는 레코드의 % 수치를 보여줌 (예상치)

• extra (얼마나 효과적인 join을 실행하고 있는지 확인 가능)

  

• select문에서 인덱스를 태우기 위해서는, 최소한 첫 번째 인덱스 조건은 where절에 포함되어야 한다

---

view

• 가상 테이블

  

---