색인 모든 열

가능한 중복 : 색인 모든 열

Why can’t I simply add an index that includes all columns?

는 인덱스 컬럼이 성능이 향상 알면, 데이터베이스의 모든 테이블의 모든 열 인덱스에 가치가있다? 그런 접근 방식의 장점/단점은 무엇입니까?

가치가 있다면 SQL Server에서 인덱스를 자동으로 만드는 방법이 있습니까? 내 응용 프로그램은 동적으로 테이블과 열을 추가하며 (사용자 구성에 따라 다름) 자동 인덱싱을하고 싶습니다.

2012-10-16 Moslem Ben Dhaou

먼저 두 개 이상의 열을 사용하는 쿼리는 두 개 이상의 열 인덱스가있는 경우보다 좋습니다. 두 번째 인덱스는 디스크 공간을 사용하므로 비어 있지 않습니다. –

또한 인덱스를 사용하면 업데이트 작업이 느려집니다. –

Ocaso : 중복이 아닙니다. 참조하는 질문은 표의 모든 열을 포함하는 1 개의 색인을 만드는 것이 좋은지 묻습니다. 이 질문은 테이블의 N 개 열 각각에 대해 N 개의 인덱스를 만드는 것이 좋은지 묻는 것입니다. –

위에서 언급 한 이유로 모든 열의 인덱싱이 유용 할 수있는 실제 시나리오를 상상하기는 어렵습니다.시나리오 유형은 여러 쿼리를 필요로하며 모두 모두 테이블의 정확히 한 열에 액세스합니다. 각 쿼리는 다른 열에 액세스 할 수 있습니다.

다른 답변은 검색어를 선택하는 동안 문제를 해결하지 못합니다. 분명히 인덱스를 관리하는 것이 문제이지만 테이블을 한 번 작성한 다음 여러 번 읽는 경우 업데이트/삽입/삭제의 오버 헤드가 고려되지 않습니다.

색인은 데이터가있는 레코드/페이지를 가리키는 원본 데이터를 포함합니다. 인덱스의 구조는 단일 값을 찾고, 순서대로 값을 검색하고, 고유 한 값의 수를 계산하고, 최소값과 최대 값을 찾는 것과 같이 빠르게 수행합니다.

인덱스는 디스크의 공간을 차지하지 않습니다. 더 중요한 것은 메모리를 차지합니다. 그리고 메모리 경합은 종종 쿼리 성능을 결정하는 요소입니다. 일반적으로 모든 열에 인덱스를 작성하면 원래 데이터보다 많은 공간을 차지하게됩니다. 한 가지 예외는 비교적 폭이 넓고 상대적으로 값이 적은 열일 것입니다.

또한 많은 쿼리를 만족하려면 에 이상의 원본 데이터가 필요합니다. 페이지 캐시는 데이터로 채워지므로 캐시 실패 횟수가 늘어나고 오버 헤드가 증가합니다.

귀하의 질문이 귀하의 데이터 구조를 적절히 모델링하지 못했다는 징후인지 궁금합니다. 사용자가 특별 임시 테이블을 작성하게하려는 경우는 거의 없습니다. 보다 일반적으로 데이터는 액세스 요구 사항을 최적화 할 수있는 미리 정의 된 형식으로 저장됩니다.

출처

2012-10-16 13:47:03

필자의 개념은 서버의 데이터베이스와 테이블 구조를 저장하는 테이블을 포함하는'master' 데이터베이스와 동일하다고 말할 수 있습니다. 여기에는 필요한 데이터가 포함되어 있습니다. –

내 데이터베이스에는 사용자가 작성한 구성을 저장하는 표준 테이블이 있습니다. 요구 사항에 따라 새 테이블을 만들 수 있습니다. 나는 디자인 타임에 그의 쿼리를 짐작할 수 없다. –

사실, 나는 현대의 DB가 인덱스 페이지를 데이터 페이지와 별도로 저장한다고 믿는다. 디스크의 총 크기가 증가하는 반면, DBMS가 인덱스를 사용하는 경우 메모리, 페이지로드 및 캐시 백분율에만 영향을 미치며 메모리로 읽습니다. 사용중인 인덱스는 선택 성능에 영향을주지 않습니다. –

아니요, 인덱스를 유지 관리하는 데 오버 헤드가 있으므로 모든 열을 인덱싱하면 삽입, 업데이트 및 삭제 작업이 모두 느려집니다. WHERE 절에서 자주 참조하는 열의 색인을 생성해야하며 이점을 볼 수 있습니다.

출처

2012-10-16 13:23:45 jalynn2

색인이 공간을 차지합니다. 또한 생성, 재구성, 유지 보수 등의 작업을 수행하는 데 시간이 걸립니다. 따라서 오래된 열의 색인 생성 성능에 대한 보장 된 수익률은 없습니다. 사용하려는 작업에 대한 성능을 제공하는 열을 색인화해야합니다. 색인은 읽기를 돕기 때문에 주로 읽는 경우 다른 테이블을 검색하여 정렬하거나 정렬하여 색인을 생성 할 색인 열을 관계형으로 색인화하십시오. 그렇지 않으면 볼 수있는 것보다 더 비쌉니다.

출처

2012-10-16 13:24:51

아니요 레코드를 추가하거나 업데이트 할 때마다 인덱스를 다시 계산해야하며 모든 열에 대해 인덱스를 작성하는 데 많은 시간이 걸리고 성능이 저하 될 수 있다는 점을 감안해야합니다.

데이터웨어 하우스와 같이 선택 쿼리 만있는 데이터베이스는 좋은 생각이지만 일반 데이터베이스에서는 좋지 않습니다.

또한 where 절에 인덱스를 추가해야하는 열을 사용하고있는 것이 아닙니다. 레코드가 기본 키처럼 거의 모든 고유하고 자주 편집하지 않는 열을 찾으십시오. 나쁜 생각은 단지 2 개의 가능한 값이 있고 그 결과가 거의 모든 레코드에서 검색 할 데이터만을 분리 할 것이기 때문에 사람의 성을 색인하는 것입니다.

출처

2012-10-16 13:25:16 Marc

+1 값 분포 참조 (사람의 성별) –

적어도 Oracle에서는 [bitmap] (http://www.oracle.com/technetwork/articles/sharma-indexes-093638.html) 색인이 존재합니다. –

매우 명확한 설명, 감사합니다! – ArchNoob

아니, 당신은 당신의 모든 열을하지 인덱스해야하고, 몇 가지 이유가이 거기에있다 : 각각의 원인이됩니다 삽입, 업데이트가 진행되는 동안 각 인덱스를 유지하거나 문을 삭제하는 비용이있다

그 거래는 오래 걸릴 것입니다.
각 인덱스가 디스크의 공간을 차지하므로 필요한 저장 공간이 늘어납니다.
열 값이 분산되지 않으면 색인이 사용/무시되지 않습니다 (예 : 성별 플래그).
복합 인덱스 (둘 이상의 열이있는 인덱스)는 자주 실행되는 WHERE, GROUP BY, ORDER BY 또는 JOIN 절의 성능에 큰 이점을 줄 수 있으며 여러 단일 인덱스를 결합 할 수 없습니다.

Explain 계획 및 데이터 액세스를 사용하고 필요한 경우 (필요한 경우에만 IMHO) 인덱스를 추가하는 것이 훨씬 더 좋습니다.

출처

2012-10-16 13:27:38

색인 모든 열

답변

관련 문제