데이터베이스 인덱스가 너무 많습니까?

나는 다소 큰 Oracle 데이터베이스로 프로젝트를 진행하고 있습니다 (내 질문은 다른 데이터베이스에도 똑같이 적용되지만). 사용자가 거의 모든 가능한 필드 조합을 검색 할 수있는 웹 인터페이스가 있습니다.

이러한 검색을 빠르게 수행하기 위해 사용자가 일반적으로 검색 할 것으로 판단되는 필드 및 필드 조합에 색인을 추가합니다. 그러나 우리는 고객이이 소프트웨어를 어떻게 사용할지 실제로 알지 못하기 때문에 어떤 인덱스를 생성해야하는지 알기가 어렵습니다.

공간은 문제가 아닙니다. 우리는 4 테라 바이트 RAID 드라이브를 가지고 있으며 그 중 극히 일부만 사용하고 있습니다. 그러나 인덱스가 너무 많으면 성능이 저하 될 수 있다는 점이 걱정입니다. 이러한 인덱스는 행이 추가, 삭제 또는 수정 될 때마다 업데이트되어야하므로 단일 테이블에 수십 개의 인덱스가있는 것은 좋지 않을 것이라고 생각합니다.

그래서 얼마나 많은 인덱스가 너무 많은 것으로 간주됩니까? 10? 25? 50? 아니면 정말 흔하고 명백한 사례 만 다루고 나머지는 모두 무시해야합니까?

테이블에서 발생하는 작업에 따라 다릅니다.

SELECT가 많고 변경 사항이 거의없는 경우 원하는 모든 항목을 인덱싱하십시오 .... 이렇게하면 SELECT 문 속도가 (잠재적으로) 빨라집니다.

테이블에 UPDATE, INSERT + DELETE가 많이 발생하는 경우 ... 이러한 작업 중 하나가 발생할 때마다 모두 수정해야하기 때문에 많은 인덱스로 인해 매우 느려집니다.

그렇긴해도 아무 작업도하지 않는 테이블에 무의미한 인덱스를 많이 추가 할 수 있습니다. 2 개의 고유 한 값이있는 열에 B- 트리 인덱스를 추가하는 것은 데이터 조회 측면에서 아무것도 추가하지 않기 때문에 의미가 없습니다. 열의 값이 고유할수록 인덱스의 이점이 더 많아집니다.

나는 보통 이렇게 진행합니다.

1. 평일 데이터에서 실행 되는 실제 쿼리 의 로그를 가져옵니다 .
2. 가장 중요한 쿼리가 실행 계획의 인덱스에 도달하도록 인덱스를 추가합니다.
3. 많은 업데이트 또는 삽입이있는 인덱싱 필드를 피하십시오.
4. 몇 개의 색인을 생성 한 후 새 로그를 얻고 반복하십시오.

모든 최적화와 마찬가지로 요청 된 성능에 도달하면 중지합니다 (이는 점 0이 특정 성능 요구 사항을 얻는다는 것을 의미합니다).

다른 사람들은 당신에게 훌륭한 조언을 해주고 있습니다. 앞으로 나아갈 때 추가 제안이 있습니다. 어느 시점에서 최상의 인덱싱 전략을 결정해야합니다. 하지만 결국 최고의 PLANNED 인덱싱 전략은 결국 사용되지 않는 인덱스를 만드는 것으로 끝날 수 있습니다. 사용되지 않는 인덱스를 찾을 수있는 한 가지 전략은 인덱스 사용량을 모니터링하는 것입니다. 다음과 같이 수행합니다.

alter index my_index_name monitoring usage;

그런 다음 v $ object_usage를 쿼리하여 해당 시점부터 인덱스 사용 여부를 모니터링 할 수 있습니다. 이에 대한 정보는 Oracle® Database Administrator 's Guide 에서 찾을 수 있습니다 .

테이블을 업데이트하기 전에 인덱스를 삭제 한 다음 다시 생성하는웨어 하우징 전략이있는 경우 모니터링을 위해 인덱스를 다시 설정해야하며 해당 인덱스에 대한 모니터링 기록을 잃게됩니다.

데이터웨어 하우징에서는 많은 수의 인덱스가있는 것이 매우 일반적입니다. 저는 200 개의 열과 190 개의 열이 인덱싱 된 팩트 테이블로 작업했습니다.

이에 대한 오버 헤드가 있지만 데이터웨어 하우스에서는 일반적으로 행을 한 번만 삽입하지만 업데이트하지 않지만 수천 개의 SELECT 쿼리에 참여할 수 있다는 점을 이해해야합니다. 열.

유연성을 극대화하기 위해 데이터웨어 하우스는 일반적으로 (압축 된) btree 인덱스를 사용할 수있는 높은 카디널리티 열을 제외하고 단일 열 비트 맵 인덱스를 사용합니다.

인덱스 유지 관리에 대한 오버 헤드는 대부분 많은 블록에 쓰는 비용과 해당 열에 대한 기존 값 범위의 "중간"에있는 값으로 새 행이 추가 될 때 블록 분할과 관련이 있습니다. 이 문제는 분할하고 분할 구성표에 맞게 새 데이터로드를 조정하고 직접 경로 삽입을 사용하여 완화 할 수 있습니다.

귀하의 질문을 더 직접적으로 해결하려면 처음에는 명백한 것을 색인화하는 것이 좋을 것이라고 생각하지만 테이블에 대한 쿼리가 도움이 될 경우 더 많은 색인을 추가하는 것을 두려워하지 마십시오.

단순성에 대한 아인슈타인 의 의역에서 필요한만큼 인덱스를 추가하고 더 이상 추가하지 마십시오.

그러나 추가하는 모든 인덱스는 데이터가 테이블에 추가 될 때마다 유지 관리가 필요합니다. 주로 읽기 전용 인 테이블에서는 많은 인덱스가 좋은 것입니다. 매우 동적 인 테이블에서는 적을수록 좋습니다.

내 조언은 일반적이고 명백한 경우를 다루고 특정 테이블에서 데이터를 가져 오는 데 더 빠른 속도가 필요한 문제가 발생하면 그 시점에서 인덱스를 평가하고 추가하는 것입니다.

또한 인덱싱이 필요한 새로운 항목이 있는지 또는 어떤 용도로도 사용되지 않고 제거해야하는 사용자가 만든 인덱스가 있는지 확인하기 위해 몇 달에 한 번씩 인덱싱 체계를 다시 평가하는 것이 좋습니다. .

비용 기반 최적화 프로그램은 다른 모든 사람들이 제기 한 점 외에도 고려할 조합이 더 많기 때문에 더 많은 인덱스가있는 경우 SQL 문에 대한 계획을 만들 때 비용이 발생합니다. SQL 문이 SQL 캐시에 남아 있도록 바인드 변수를 올바르게 사용하여이를 줄일 수 있습니다. 그런 다음 Oracle은 소프트 구문 분석을 수행하고 마지막에 찾은 계획을 재사용 할 수 있습니다.

항상 그렇듯이 간단한 것은 없습니다. 치우친 열과 히스토그램이 관련되어 있다면 이것은 나쁜 생각 일 수 있습니다.

웹 애플리케이션에서는 허용되는 검색 조합을 제한하는 경향이 있습니다. 그렇지 않으면 언젠가 누군가가 발견하게 될 숨어있는 문제가 없는지 확인하기 위해 말 그대로 모든 조합의 성능을 테스트해야합니다. 또한 리소스 제한을 구현하여 문제가 발생할 경우 응용 프로그램의 다른 곳에서 문제를 일으키지 않도록했습니다.

실제 프로젝트와 실제 MySql 데이터베이스에서 몇 가지 간단한 테스트를했습니다. 이 주제에서 이미 대답했습니다. 여러 db 열을 인덱싱하는 데 드는 비용은 얼마입니까?

그러나 여기에 인용하면 더 좋을 것이라고 생각합니다.

실제 프로젝트와 실제 MySql 데이터베이스를 사용하여 간단한 테스트를했습니다.

내 결과는 다음과 같습니다. 평균 인덱스 (인덱스의 1-3 열)를 테이블에 추가하면 삽입 속도가 2.1 % 느려집니다. 따라서 20 개의 인덱스를 추가하면 삽입 속도가 40-50 % 느려집니다. 그러나 선택은 10-100 배 더 빠릅니다.

많은 인덱스를 추가해도 괜찮습니까? -상황에 따라 다름 :) 내가 당신에게 내 결과를 줬어요-당신이 결정 해요!

궁극적으로 필요한 인덱스 수는 데이터베이스 서버 위에있는 애플리케이션의 동작에 따라 다릅니다.

일반적으로 더 많이 삽입할수록 인덱스가 더 고통스러워집니다. 삽입을 수행 할 때마다 해당 테이블을 포함하는 모든 인덱스를 업데이트해야합니다.

이제 응용 프로그램에 적절한 양의 읽기가 있거나 거의 모든 읽기 인 경우 인덱스가 갈 길입니다. 아주 적은 비용으로 주요 성능 향상이있을 것입니다.

제 생각에는 정적 인 대답이 없습니다. 이런 종류의 것은 '성능 튜닝'에 해당합니다.

앱이 수행하는 모든 작업이 기본 키로 조회되거나 쿼리가 제한되지 않은 필드 조합에 대해 수행되고 특정 시간에 특정 항목을 사용할 수 있다는 점에서 반대 일 수 있습니다.

인덱싱 외에도 계산 된 검색 필드, 분할 테이블 등을 포함하도록 DB를 다시 집계합니다. 이는 실제로로드 형태 및 쿼리 매개 변수, 쿼리에서 '실제로'되돌려 야하는 데이터의 양 / 무엇에 따라 달라집니다.

모든 임시 쿼리에 대해 걱정할 필요가 없기 때문에 전체 DB가 저장 프로 시저 파사드를 앞지르는 것이 조금 더 쉬워집니다. 또는 DB에 도달 할 쿼리의 종류를 깊이 이해하고 튜닝을 제한 할 수 있습니다.

SQL Server의 경우 데이터베이스 엔진 튜닝 관리자가 유용하다는 것을 알았습니다. '일반적인'워크로드를 설정하면 인덱스 및 통계 추가 / 제거에 대한 권장 사항을 만들 수 있습니다. 다른 DB에도 '공식'또는 타사와 유사한 도구가 있다고 확신합니다.

이것은 실제보다 더 이론적 인 질문입니다. 성능에 대한 인덱스 영향은 보유한 하드웨어, Oracle 버전, 인덱스 유형 등에 따라 다릅니다. 어제 Oracle이 11g 데이터베이스에서 10 배 더 빠른 성능을 발휘할 것으로 예상되는 HP에서 만든 전용 스토리지를 발표했다고 들었습니다. 귀하의 경우에는 다음과 같은 몇 가지 솔루션이있을 수 있습니다. 1. 많은 양의 인덱스 (> 20)를 가지고 매일 (야간) 다시 빌드합니다. 테이블이 매일 수천 건의 업데이트 / 삭제를받는 경우 특히 유용합니다. 2. 테이블을 분할합니다 (데이터 모델이 적용되는 경우). 3. 새로운 / 업데이트 된 데이터에 대해 별도의 테이블을 사용하고 데이터를 함께 결합하는 야간 프로세스를 실행합니다. 이를 위해서는 응용 프로그램 논리를 변경해야합니다. 4. 데이터가이를 지원하는 경우 IOT (인덱스 구성 테이블)로 전환하십시오.

물론 그러한 경우에 더 많은 솔루션이있을 수 있습니다. 첫 번째 제안은 DB를 개발 환경에 복제하고 이에 대해 스트레스 테스트를 실행하는 것입니다.

대부분 읽기 (및 업데이트가 거의 없음)를 수행하는 경우 색인에 필요한 모든 항목을 색인화하지 않을 이유가 없습니다. 자주 업데이트하는 경우 보유한 인덱스 수에주의해야 할 수 있습니다. 어려운 숫자는 없지만 상황이 느려지기 시작하면 알 수 있습니다. 클러스터형 인덱스가 데이터를 기반으로 가장 적합한 인덱스인지 확인하십시오.

고려할 수있는 한 가지 사항은 표준 검색 조합을 대상으로하는 색인을 작성하는 것입니다. column1이 일반적으로 검색되고 column2가 자주 사용되며 column3이 종종 column2 및 column1과 함께 사용되는 경우 해당 순서로 column1, column2 및 column3의 인덱스를 이러한 세 가지 상황 중 하나에 사용할 수 있습니다. 유지해야하는 하나의 인덱스 만 있습니다.

인덱스는 기본 테이블이 업데이트 될 때 비용을 부과합니다. 인덱스는 쿼리 속도를 높이는 데 사용될 때 이점을 제공합니다. 각 지수에 대해 이익과 비용의 균형을 맞춰야합니다. 인덱스없이 쿼리가 얼마나 느리게 실행됩니까? 어느 정도의 이점이 더 빨리 실행되고 있습니까? 귀하 또는 귀하의 사용자가 색인이 누락 된 경우 느린 속도를 견딜 수 있습니까?

업데이트를 완료하는 데 걸리는 추가 시간을 허용 할 수 있습니까?

비용과 이점을 비교해야합니다. 그것은 당신의 상황에 따라 다릅니다. "너무 많음"의 임계 값을 통과하는 인덱스의 매직 넘버는 없습니다.

인덱스를 저장하는 데 필요한 공간 비용도 있지만 상황에 따라 문제가되지 않는다고 말씀하셨습니다. 디스크 공간이 얼마나 저렴한지를 고려할 때 대부분의 상황에서 마찬가지입니다.

몇 개의 열이 있습니까? 저는 항상 다중 열 인덱스가 아닌 단일 열 인덱스를 만들라는 지시를 받았습니다. 따라서 IMHO의 열 수보다 더 많은 인덱스가 없습니다.

실제로 내려지는 것은 업데이트 된 것보다 훨씬 더 자주 사용된다는 것을 알지 못하는 한 (그리고 종종 사용 통계 수집을 의미하는) 인덱스를 추가하지 마십시오.

해당 기준을 충족하지 않는 인덱스는 사용 된 이상한 경우에 인덱스를 사용하지 않는 것보다 다시 작성하는 데 더 많은 비용이 듭니다.

SQL Server는 실제로 사용되는 인덱스를 확인할 수있는 몇 가지 좋은 도구를 제공합니다. 이 기사 ( http://www.mssqltips.com/tip.asp?tip=1239) 에서는 인덱스가 얼마나 많이 업데이트되는지와 달리 인덱스가 얼마나 많이 사용되는지 더 잘 파악할 수있는 몇 가지 쿼리를 제공합니다.

Where 절에서 사용되는 열을 전적으로 기반으로합니다. 규칙의 엄지 손가락으로 DEADLOCKS를 방지하려면 외래 키 열에 인덱스가 있어야합니다. AWR 보고서는 인덱스의 필요성을 이해하기 위해 주기적으로 분석해야합니다.