[database] 데이터베이스 인덱스가 너무 많습니까?
나는 다소 큰 Oracle 데이터베이스로 프로젝트를 진행하고 있습니다 (내 질문은 다른 데이터베이스에도 똑같이 적용되지만). 사용자가 거의 모든 가능한 필드 조합을 검색 할 수있는 웹 인터페이스가 있습니다.
이러한 검색을 빠르게 수행하기 위해 사용자가 일반적으로 검색 할 것으로 판단되는 필드 및 필드 조합에 색인을 추가합니다. 그러나 우리는 고객이이 소프트웨어를 어떻게 사용할지 실제로 알지 못하기 때문에 어떤 인덱스를 생성해야하는지 알기가 어렵습니다.
공간은 문제가 아닙니다. 우리는 4 테라 바이트 RAID 드라이브를 가지고 있으며 그 중 극히 일부만 사용하고 있습니다. 그러나 인덱스가 너무 많으면 성능이 저하 될 수 있다는 점이 걱정입니다. 이러한 인덱스는 행이 추가, 삭제 또는 수정 될 때마다 업데이트되어야하므로 단일 테이블에 수십 개의 인덱스가있는 것은 좋지 않을 것이라고 생각합니다.
그래서 얼마나 많은 인덱스가 너무 많은 것으로 간주됩니까? 10? 25? 50? 아니면 정말 흔하고 명백한 사례 만 다루고 나머지는 모두 무시해야합니까?
답변
테이블에서 발생하는 작업에 따라 다릅니다.
SELECT가 많고 변경 사항이 거의없는 경우 원하는 모든 항목을 인덱싱하십시오 …. 이렇게하면 SELECT 문 속도가 (잠재적으로) 빨라집니다.
테이블에 UPDATE, INSERT + DELETE가 많이 발생하는 경우 … 이러한 작업 중 하나가 발생할 때마다 모두 수정해야하기 때문에 많은 인덱스로 인해 매우 느려집니다.
그렇긴해도 아무 작업도하지 않는 테이블에 무의미한 인덱스를 많이 추가 할 수 있습니다. 2 개의 고유 한 값이있는 열에 B- 트리 인덱스를 추가하는 것은 데이터 조회 측면에서 아무것도 추가하지 않기 때문에 의미가 없습니다. 열의 값이 고유할수록 인덱스의 이점이 더 많아집니다.
답변
나는 보통 이렇게 진행합니다.
- 평일 데이터에서 실행 되는 실제 쿼리 의 로그를 가져옵니다 .
- 가장 중요한 쿼리가 실행 계획의 인덱스에 도달하도록 인덱스를 추가합니다.
- 많은 업데이트 또는 삽입이있는 인덱싱 필드를 피하십시오.
- 몇 개의 색인을 생성 한 후 새 로그를 얻고 반복하십시오.
모든 최적화와 마찬가지로 요청 된 성능에 도달하면 중지합니다 (이는 점 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 배 더 빠릅니다.
많은 인덱스를 추가해도 괜찮습니까? -상황에 따라 다름 🙂 내가 당신에게 내 결과를 줬어요-당신이 결정 해요!
