데이터베이스가 자체 색인을 자동으로 작성하지 않는 이유는 무엇입니까?

데이터베이스가 자주 발생하는 것에 대해 충분히 알고 있고 요청이 많은 데이터에 인덱스를 추가하기로 결정한 요구에 응답 할 수 있다고 생각했을 것입니다.

최신 정보

이것은 이제 SQL Server Azure에서 구현됩니다. 추천을 생성합니다

인덱스 관리 를 자동으로 구성 할 수 있습니다 .

자동 인덱스 관리 활성화

SQL Database Advisor가 권장 사항을 자동으로 구현하도록 설정할 수 있습니다. 권장 사항이 제공되면 자동으로 적용됩니다. 서비스가 관리하는 모든 인덱스 작업과 마찬가지로 성능 영향이 부정적인 경우 권장 사항이 되돌려집니다.

원래 답변

일부 데이터베이스는 이미 인덱스를 자동으로 생성합니다.

SQL Server에서 실행 계획에 때때로 인덱스 스풀이 포함될 수 있습니다. 에 RDBMS가 동적으로 색인화 된 데이터 사본을 작성하는 연산자가 . 그러나이 스풀은 원본 데이터와 동기화 된 데이터베이스의 영구적 인 부분이 아니며 쿼리 실행간에 공유 할 수 없습니다. 즉, 이러한 계획의 실행으로 인해 동일한 데이터에 임시 인덱스가 반복적으로 생성되어 삭제 될 수 있습니다.

아마도 앞으로 RDBMS는 워크로드에 따라 동적 인덱스를 동적으로 삭제하고 작성할 수있는 능력을 갖게 될 것입니다.

인덱스 최적화 프로세스는 결국 비용 편익 분석입니다. 사람이 작업 부하에서 쿼리의 상대적 중요성에 대해 더 많은 정보를 가질 수있는 것은 사실이지만,이 정보를 옵티 마이저에게 제공 할 수없는 이유는 없습니다. SQL Server에는 이미 리소스 관리자가있어 세션을 우선 순위에 따라 리소스 할당이 다른 여러 작업 그룹으로 분류 할 수 있습니다.

Kenneth가 언급 한 누락 된 인덱스 DMV는 특정 쿼리의 이점 만 고려하고 다른 쿼리에 대한 잠재적 인덱스의 비용을 고려하지 않기 때문에 맹목적으로 구현되지 않습니다. 비슷한 누락 된 인덱스도 통합하지 않습니다. 예를 들어이 DMV의 출력은 누락 된 인덱스를보고 할 수 있습니다.A,B,C 및A,B INCLUDE(C)

아이디어와 관련된 몇 가지 현재 문제는

• 실제로 지수를 생성하지 않는 자동 분석의 품질은 원가 계산 모델의 정확성에 크게 좌우됩니다.
• 자동화 된 분석 분야에서도 오프라인 솔루션은 온라인 솔루션보다 더 철저 할 수 있습니다. 온라인 솔루션은 라이브 서버에 오버 헤드를 유지하는 대형 책을 추가하지 않아야하며 쿼리 실행의 기본 목적을 방해하지 않아야하기 때문입니다.
• 워크로드에 대한 응답으로 자동 생성 된 인덱스는 반드시 유용한 쿼리에 대한 응답으로 생성되므로 미리 인덱스를 생성하는 솔루션보다 뒤떨어집니다.

원가 계산 모델의 정확성이 시간이 지남에 따라 개선 될 것으로 예상하는 것이 합리적이지만 포인트 2는 해결하기가 까다로워지고 포인트 3은 본질적으로 불용성입니다.

그럼에도 불구하고, 대부분의 설치는 워크로드의 변화를 지속적으로 모니터링, 진단 및 예측 (또는 적어도 반응)하는 숙련 된 직원이 이상적인 상황에 있지 않을 수 있습니다.

1996 년부터 Microsoft Research 의 AutoAdmin 프로젝트 가 실행되었습니다.

이 프로젝트의 목표는 작업량에 대한 지식을 활용하여 데이터베이스 자체 조정 및 자체 관리를 만드는 것입니다.

프로젝트 홈 페이지에는 여러 가지 흥미로운 프로젝트가 나열되어 있습니다. 하나는 특히 여기서 질문과 관련이 있습니다

사용 가능한 DBA가없는 경우 (예 : 임베디드 데이터베이스 또는 소규모 비즈니스) 또 다른 흥미로운 문제점이 발생합니다. 이러한 시나리오에서는 낮은 터치 연속 인덱스 튜닝 방법이 중요해질 수 있습니다. ICDE 2007에서 "[ 물리적 디자인 튜닝에 대한 온라인 접근 방법 "에 대한 해결책을 모색했습니다 .

저자 상태

온라인 색인과 같은 점점 더 일반적인 DBMS 기능으로 인해 최신 기술을 발전시키는 물리적 설계 문제에 대한보다 자동적 인 솔루션을 탐색하는 것이 매력적입니다.

이 논문은 알고리즘을 소개합니다

주요 특징은 다음과 같습니다.

• 쿼리가 최적화됨에 따라 성능을 향상시킬 수있는 관련 후보 인덱스 집합을 식별합니다. 이 기능을 사용하면 백그라운드에서 작성된 인덱스와 함께 쿼리 처리를 계속할 수 있습니다.
• 실행시, 쿼리, 업데이트 및 공간 제약 조건이있을 때 이러한 후보 인덱스와 기존 인덱스의 유틸리티가 없어서 손실 가능성을 추적합니다.
• 물리적 설계 변경이 유익하다는 충분한 증거를 수집 한 후에는 인덱스 작성 또는 삭제를 자동으로 트리거합니다.
• 문제의 온라인 특성은 일반적으로 미래를 알고있는 최적의 솔루션보다 뒤 떨어질 것임을 암시합니다. 그러나 증거를 신중하게 측정함으로써“늦은”결정으로 인해 심각한 손실을 입지 않도록함으로써 발생하는 손실의 양을 제한합니다

알고리즘을 구현하면 서버로드 변경에 대한 응답으로 제한을 수행 할 수 있으며 생성 중에 워크로드 변경 및 예상 이점이 가치가 있다고 간주되는 지점 아래로 떨어지면 인덱스 생성을 중단 할 수 있습니다.

온라인 대 기존 물리적 튜닝 에 대한 저자의 결론 .

이 작업의 온라인 알고리즘은 DBA가 워크로드의 향후 동작에 대해 확실하지 않거나 포괄적 인 분석 또는 모델링을 수행 할 가능성이없는 경우에 유용합니다. DBA에 워크로드 특성에 대한 전체 정보가있는 경우 기존 도구 (예 : [2, 3])에 의한 정적 분석 및 배치가 더 나은 대안입니다.

여기에있는 결론은 다른 논문의 자율 쿼리 기반 인덱스 튜닝 과 비슷합니다.

전체 워크로드를 미리 알고 있으면 인덱스 어드바이저를 이길 수 없습니다. 그러나 진화하고 변화하는 워크로드가있는 동적 환경에서는 쿼리 기반 접근 방식으로 더 나은 결과를 얻을 수 있습니다.

당신이 배치 한 인덱스 디자인은 과학보다 예술에 가깝습니다. RDBMS는 일반적인 워크로드를 수행하고 스마트 인덱싱 전략을 설계하기에 충분하지 않습니다. 워크로드를 분석하고 가장 적합한 방법을 결정하는 것은 사람의 개입 (읽기 : DBA)에 달려 있습니다.

인덱스에 대한 페널티가 없다면 무한한 수의 인덱스를 추가하는 것이 샷건 접근법 일 것입니다. 그러나 데이터 수정 (INSERTS, UPDATES 및 DELETES)이 테이블의 활성화 된 인덱스에 영향을 미치므로 이러한 인덱스의 변수 오버 헤드가 발생합니다.

최소한의 데이터 수정 오버 헤드를 가지면서 읽기 성능을 극대화 할 수있는 인덱스를 스마트하게 만들려면 사람의 디자인과 전략이 필요합니다.

실제로이를 수행하는 일부 데이터베이스가 있습니다. 예를 들어, Google의 BigTable 및 Amazon의 SimpleDB는 자동으로 인덱스를 생성합니다 (RDBMS도 아님) . 이를 수행하는 하나 이상의 MySQL RDBMS 엔진도 있습니다. 또한 SQL Server는 실제로 만들어야하는 인덱스 는 아니지만 실제로 만들어야 할 인덱스를 추적 합니다.

이 문제는 놀랍게도 수정하기가 어렵 기 때문에 대부분의 데이터베이스가 자동으로 데이터베이스를 생성하지 않는다는 것은 놀라운 일이 아닙니다 . 또한 인덱스를 즉석에서 생성하는 것은 전체 테이블에 독점적으로 액세스해야하는 시간이 많이 걸리는 프로세스입니다. 테이블이 온라인 상태 일 때 원하는 것은 아닙니다.

그러나 인덱스 가 무엇인지조차 모르는 아마추어가 작성한 LAMP 웹 애플리케이션의 수를 감안할 때이 기능은 여전히 ​​일부 사람들에게 도움이 될 것이라고 생각합니다.

이미 광범위한 답변이 있지만 실제 답변을 둘러싼 것처럼 보입니다. 색인이 항상 바람직한 것은 아닙니다.

댓글에 언급 된 자동차 비유를 통해 왜 모든 자동차에 익스트림 스포츠 패키지가 장착되어 있지 않은지 더 잘 알 수 있습니다. 부분적으로는 비용이 들지만, 많은 사람들이 로우 프로파일 타이어를 필요로하지 않거나 단단한 서스펜션을 필요로한다는 사실에 달려 있습니다. 불필요하게 불편합니다.

따라서 모든 인서트에 대해 1,000 개의 읽기가있을 수 있습니다. 자동 생성 된 인덱스가없는 이유는 무엇입니까? 테이블이 넓고 쿼리가 다양하다면 왜 여러 개가 있습니까? 아마도 커밋은 시간이 중요하고 읽기는 그렇지 않습니다. 상황에 따라 삽입 속도를 늦출 수 없습니다. 디스크 공간이 제한되어 작업하고있는 공간에 추가 인덱스를 사용할 여유가 없을 수도 있습니다.

요점은 인덱스가 모든 것에 대한 답이 아니기 때문에 자동으로 생성되지 않는다는 것입니다. 인덱스 디자인은 단순히 "이것이 내 읽기 속도를 높일 것입니다"라고 말하는 것이 아니라 고려해야 할 다른 요소가 있습니다.

그들은 과거의 쿼리를 분석하고 인덱스를 제안 / 생성 할 수 있지만 인덱스가 균형을 맞추고 비용으로 최적화하려는 것을 가속화 하고 서버가 의도를 알 수 없기 때문에 이것이 최적으로 작동하지 않습니다 .

그들은 똑똑하지 않고 코드 조각입니다. 데이터베이스에 새 데이터를 입력 할 때마다 데이터베이스에서 새 위치를 찾고 요청시이를 찾기위한 맵을 찾아야합니다. 인덱싱 사운드가 그 어느 때보 다 쉬워졌습니다. 새로운 데이터 청크에 새로운 숫자를 부여 하시겠습니까? 다음 쿼리가 마지막 데이터 청크가 아니라 약 36271 청크 정도라면 어떨까요? 색인으로 쉽게 찾을 수 있습니다. 그러나 쿼리에 1997 년에 만들어진 36271 청크에서 찾을 수있는 "낚시"와 같은 단어가 포함되어 있다면 어떨까요? 호? 이전 기사에서 낚시에 관한 단어는 없습니다.

데이터가 데이터베이스에 하나씩 들어 오면 색인을 생성 할 수 있습니다. 그러나 간단한 색인 생성은 조만간 잘못된 결과 및 / 또는 성능 저하를 초래합니다 ...