SQL Server 2000 인덱스 - 클러스터형 대 비 클러스터형

Question

클러스터형 인덱스와 각 클러스터형 인덱스에 대한 중복 인덱스가있는 데이터베이스를 상속했습니다.

예 : IX_PrimaryKey는 열 ID에서 클러스터 된 색인입니다. IX_ID는 열 ID에서 클러스터되지 않은 색인입니다.

중복되지 않은 클러스터 된 인덱스를 정리하고이를 수행 할 이유가 있는지 확인하고 싶습니다.

누구든지이 작업을 수행하면 성능 이점을 생각할 수 있습니까?

Answer 1

동일한 인덱스의 경우 성능이 향상되지 않습니다. 실제로 삽입 및 업데이트시 성능 손실이 발생하고이 발생합니다. 그러나 열 순서가 다른 여러 열 인덱스가있는 경우 유효한 이유가있을 수 있습니다.

Answer 2

어쩌면 나는 충분히 열심히 생각하고 있지 않지만 어쨌든 이것을 할 이유가 없다. 클러스터 된 인덱스의 특성은 데이터가 인덱스 순서로 구성된다는 것입니다. 여분의 지수는 완전한 낭비 인 것으로 보인다. BOL을 파고이 질문을보고

,하지만 ...

Answer 3

이 일에 대한 합리적인 이유가 보인다 및 성능 저하가있다.

내가 할 수있는 유일한 생각은 매우 좁은 행 너비로 색인을 작성하여 페이지 당 행 수가 매우 많아 스캔/탐색이 매우 빠르다는 것입니다. 그러나 다른 필드 (같은 값인 클러스터 된 키 제외)가 없기 때문에 여전히 그 이유를 알 수 없습니다.

원본 작성자가 PK가 클러스터 된 인덱스를 기본값으로 설정하고 복제본임을 인식하지 않고 NC 인덱스를 만들었습니다.

Answer 4

기본 키 제약 조건이 지정된 경우 SQL Server가 클러스터 된 인덱스를 자동으로 만들었을 것이라고 추측합니다 (다른 인덱스 (클러스터되지 않은/클러스터 된)가없는 경우에 발생합니다). 기본 키 열에 대해 클러스터되지 않은 인덱스를 만들었을 수 있습니다.

이러한 시나리오는 다음과 같습니다 삽입/삭제/업데이트가 일어날 때 인덱스가 업데이트 될 때

• 성능에 일부 부정적인 영향을 미친다.
• 추가 디스크 공간을 사용하십시오.
• 교착 상태가 발생할 수 있습니다.
• 데이터베이스의 백업/복원에 더 많은 시간을 기여합니다.

환호

Answer 5

클러스터 된 기본 키를 제작하는 낭비가 될 것입니다. WHERE ID = 10을 사용하여 레코드를 검색하는 쿼리가 없다면?

WHERE City = 'Sydney'에서 자주 질의 될 열에 클러스터 된 인덱스를 만들 수 있습니다. Clustered는 SQL이 클러스터 된 인덱스를 기반으로 테이블의 데이터를 그룹화 함을 의미합니다. 테이블의 City 값을 그룹화하면 SQL이 데이터를 더 빠르게 검색 할 수 있습니다.

Answer 6

동일한 데이터에 두 개의 인덱스를 저장하면 데이터를 유지하는 데 필요한 디스크 공간과 처리가 낭비됩니다.

그러나 IX_PrimaryKey이라는 색인의 존재 여부에 따라 달라지는 제품을 상상할 수 있습니다. E.G.

string queryPattern = "select * from {0} as t with (index(IX_PrimaryKey))"; 

당신은 잎이 실제 데이터이기 때문에 클러스터 된 인덱스 자체가 다른 사람보다 훨씬 적은 공간을 차지한다는 주장을 할 수 있습니다. 반면에 클러스터 된 인덱스는 페이지 분할에 더 취약 할 수 있으며 일부 인덱스는 클러스터되지 않은 것이 좋습니다.

• 코드하는 위와 같이 알려진 인덱스 이름에 따라 달라집니다 : 나쁜 일이 될 것이다 중복 인덱스를 제거하는 경우

  함께이 퍼팅, 나는 확실히 시나리오를 생각할 수 있습니다.

• 클러스터 된 인덱스를 클러스터되지 않은 인덱스로 변경할 수있는 코드.
• IX_PrimaryKey의 유무를 사용하여 테이블을 특정 방식으로 처리하는 코드입니다.

나는이 좋은 디자인을 고려하지 않았지만 나는 그것을하는 누군가를 상상할 수있다. (당신이 DailyWTF이 게시 있나요?)

가 동일하지 않은 중복 인덱스해야 할 의미가 어디에 경우가 있습니다 : 당신이 ID에 의해 엄격하게 찾는 경우

create index IX_1 on table1 (ID) 
create index IX_2 on table1 (ID, TYPE, ORDER_DATE, TOTAL_CHARGES) 

, SQL 최적화하고 사용 할 수 있습니다 IX_1. ID, TYPE, ORDER_DATE을 기반으로 쿼리를 실행하고 TOTAL_CHARGES을 합산하는 경우 SQL은 IX_2을 "커버 인덱스"로 사용하여 테이블을 건드리지 않고도 인덱스의 모든 쿼리 세부 정보를 만족시킬 수 있습니다. 일반적으로 이것은 광범위한 테스트를 거친 후에 성능 튜닝 과정에서 추가하는 것입니다.

정확하게 동일한 필드에서 두 개의 인덱스에 대한 주어진 예를 보면, 나는 큰 적합성을 보지 못합니다. 아마도 SQL은 에서 값의 존재를 확인하고 차단을 무시할 때 IX_ID을 "커버 인덱스"로 사용할 수 있습니까?