우리 대부분은 아마도 데이터베이스 인덱스를 사용하는 것이 좋다는 데 동의 할 것입니다. 색인이 너무 많으면 성능이 실제로 저하 될 수 있습니다.
일반적으로 어떤 필드를 색인화해야합니까?
어떤 필드를 색인화하지 않아야합니까?
성능 저하가 아닌 성능 향상을 달성하기 위해 너무 많은 인덱스와 충분하지 않은 인덱스 사이의 균형을 유지하면서 인덱스를 사용하는 규칙은 무엇입니까?
답변:
"너무 많은 인덱스"규칙은 약간 오해의 소지가 있습니다.
평균 데이터베이스가 약 98 %의 읽기 (또는 더 높은) 읽기 인 경우 최적화가 필요합니다. 예를 들어, 고유 색인이있는 경우 INSERT를 읽습니다. 또는 업데이트에 대한 WHERE. 쓰기 집약적 인 데이터베이스조차도 여전히 85 % 읽기라는 것을 읽었습니다.
품질 인덱싱이 좋지 않습니다. 예 :
cold, cole및cold, cole, colf)OLTP 시스템에서도 실제 데이터보다 몇 배 더 큰 인덱스를 갖는 것이 일반적입니다.
일반적으로
그런 다음 살펴 보겠습니다.
말하자면, 시스템을 조정하기 위해 상황이 어떻게 펼쳐지는지 (100 억 행 후에) 본 후 일부 시스템에서 이러한 규칙을 어겼습니다. 그러나 내가 왜 그렇게하는지 보여줄 수 없다면 색인 생성을 고려 하지 않을 것 입니다.
Gail Shaw가 선택한 인덱스와 그 이유에 대해 작성된 최고의 시리즈 중 하나입니다. 여기 를 클릭하여 기사를 찾을 수 있습니다
당신이 묻는 질문은 50 가지 다른 방법으로 답변 될 수 있습니다. 실제로는 모든 데이터와 쿼리 방법으로 요약됩니다. 일반적인 규칙은 힙을 피하기 위해 항상 각 테이블에 클러스터형 인덱스가 있어야한다는 것입니다. 클러스터형 인덱스는 일반적으로 가능한 작아야합니다. 테이블에 클러스터 된 인덱스가있는 경우 비 클러스터형 인덱스의 리프 페이지에있는 모든 인덱스 레코드는 책갈피 조회를 위해 해당 클러스터형 인덱스의 레코드 값을 저장합니다. 테이블이 힙인 경우 SQL은 책갈피 조회를위한 고유 식별자를 작성합니다. 8 또는 16 바이트 크기를 기억할 수 없습니다. 이것은 훨씬 더 큰 데이터 유형이되고 INT라고 할 수 있습니다. 힙 테이블에 8 개의 비 클러스터형 인덱스가 있다고 상상해보십시오.
다른 데이터베이스에는 다른 전략이 필요하다는 것을 여기에 추가하고 싶습니다. 예를 들어 InnoDB와 PostgreSQL이있는 MySQL을 비교해 봅시다.
InnoDB
InnoDB 테이블은 기본적으로 인덱스 키에 행 정보를 포함하도록 확장 된 기본 키의 b- 트리 인덱스입니다. 물리적 순서 스캔은 지원되지 않으며 모든 스캔은 논리적 순서로 수행됩니다. 이것은 두 가지를 의미합니다.
Innodb의 순차적 스캔은 많은 랜덤 디스크 I / O를 생성합니다.
기본 키 인덱스는 보조 인덱스를 사용하는지 여부에 관계없이 통과해야합니다.
기본 키 조회는 다른 접근 방식보다이 모델에서 더 빠릅니다.
이 경우 여러 페이지 테이블에서 충분한 필드를 색인화하는 것이 매우 중요합니다. 일반적인 규칙은 필터링하려는 모든 항목을 색인화하는 것입니다.
PostgreSQL
PostgreSQL은 파일 당 하나의 테이블 (일부 테이블은 많은 파일 일 수 있음) 인 힙 파일을 사용하며,이 힙의 여유 공간에서 튜플이 할당됩니다. 실제 주문 스캔이 지원됩니다. 논리적 순서 스캔이 작동하려면 인덱스를 추가해야합니다.
PostgreSQL의 기본 키는 기본적으로 값이 NULL이 아닌 고유 인덱스의 하위 집합입니다. UNIQUE 제약 조건은 암시 적 인덱스를 사용하여 수행되며 여러 다른 인덱스 유형이 인덱스에서 가능한 다른 작업으로 지원됩니다.
이것은 다음을 의미합니다.
상당히 큰 테이블이 인덱스 파일 과 테이블 파일에 도달해야한다고 가정 할 때 기본 키 조회 . 이것은 인덱스 만 통과하고 행이 인덱스에 포함되는 MySQL의 접근 방식보다 상당히 느립니다.
물리적 순서 스캔은 훨씬 더 나은 성능을 발휘하여 많은 수의 행이 처리되는 임의의 디스크 I / O를 줄입니다.
2 차 인덱스 스캔은 테이블의 실제 부분에 도달하기 위해 하나의 인덱스 만 통과해야하므로 MySQL보다 성능이 우수합니다.
이 모델에서 색인은 종종 필요하지만 플래너는 색인을 사용할 때 더 많은 자유를 가지며, 색인을 사용하지 않는 의미는 덜 심각합니다. 테이블은 pkey 조회를 전문화하지 않고보다 일반적으로 최적화되므로 더 적은 인덱스가 필요합니다.
TL; DR
당신의 RDBMS를 아십시오.
Oracle 11.2 Concepts Guide에서 :
11.2 성능 조정 안내서에서 :
11.2 관리자 안내서에서 :