기본 키 대신 커버링 열이있는 고유 한 비 클러스터형 인덱스를 사용하는 의미

우리는 큰 테이블이 [MyTable]현재 모두를 가지고 Primary Key, 그리고Unique Non Clustered Index 같은 열에 ( [KeyColumn]). U NC 인덱스에는 추가 커버링 열이 있습니다.

동일한 열에 PK와 고유 NC 인덱스가 모두 중복 된 것으로 보이므로 기본 키를 삭제하는 대신 참조 무결성 목적으로 고유 비 클러스터형 인덱스를 사용하는 것을 고려하고있었습니다.

테이블은 다른 열에 의해 전체적으로 클러스터됩니다.

즉 우리는 :

ALTER TABLE [MyTable]
    ADD CONSTRAINT [PK_MyTable] 
    PRIMARY KEY NONCLUSTERED ([KeyColumn])
GO

과

CREATE UNIQUE NONCLUSTERED INDEX [IX_MyTable_SomeIndex] 
    ON [MyTable] ([KeyColumn]) 
    INCLUDE ([Column1], [Column2])
GO

내가 아는 한 기본 키에 포함 열을 추가 할 수 없으므로 다음과 같이하십시오.

• 에 의존하는 외래 키 제약 조건 제거 MyTable.KeyColumn
• 기본 키를 MyTable.KeyColumn완전히 삭제
• 외래 키를 테이블에 다시 추가합니다 (예 : RI를 통해 시행 MyTable.KeyColumn)

내가 이것을 생각할 수있는 유일한 의미는 ERD 다이어그램에서 시각적 키 기호를 얻지 못하고 포함 된 열 때문에 (잎) 인덱스 밀도가 적다는 것입니다.

/programming/487314/primary-key-or-unique-index를 읽었 으며이 작업 의 무결성 및 성능 측면에 만족합니다.

내 질문은 :이 접근 방식에 결함이 있습니까?

내가 달성하려는 것을 편집하십시오 : 성능 최적화 및 스프링 청소 . PK 또는 인덱스를 제거하면 인덱스에 필요한 페이지 수가 줄어 듭니다. 쓰기 속도가 빠를뿐 아니라 유지 관리 / 운영상의 이점도 있습니다.

이에 대한 배경 지식을 얻기 위해 PK없이 참조되는 테이블을 본 적이 없습니다. 그러나 열을 덮고있는 NC 인덱스가 테이블에 추가되었다는 사실은 내 생각을 조정해야한다는 것을 의미합니다.

성능 최적화. PK 또는 인덱스를 제거하면 인덱스에 필요한 페이지 수가 줄어 듭니다. 쓰기 속도가 빠를뿐만 아니라 유지 관리 / 운영상의 이점도 있습니다 (예 : 조각 모음을 유지하기위한 인덱스 하나 감소 등).

제안 된 내용이 실제로 도움이 될 것임을 증명할 수 있어야합니다 (비용 대비 이익). 어떤 이유로이 변경이 고려됩니까? 이 테이블에 실제로 성능 문제가 있습니까, 아니면 "잘못된 것"입니까?

다음은 환경에 가장 적합한 결정을 내리는 데 도움이되는 몇 가지 다른 질문입니다.

• 유지 관리 기간에 얼마나 많은 시간이 절약됩니까? 백업 창에서?

• 저장 공간 (데이터 파일, 로그 파일, 백업 등)이 얼마나됩니까?

• 가 INSERT이 테이블에 성능은 정말 병목 지금? 얼마나 향상 될까요? 색인을 제거하는 것이 그 문제를 해결하기위한 최선의 전략입니까?

• 이로 인해 각 테이블에 고유 인덱스뿐만 아니라 기본 키가있는 데이터베이스 도구 및 프레임 워크 (특히 ORM)에 문제가 발생합니까? 트랜잭션 복제 에는 게시 된 테이블에 기본 키 가 필요 합니다.

• 자체 문서화 데이터베이스 스키마가 중요합니까?

• 제한된 사용에도 불구하고 기본 키 인덱스의 범위가 좁아도 옵티마이 저가 특정 쿼리에 대해보다 효율적인 계획을 생성 할 수 있습니까? ( sys.dm_db_index_usage_stats찾을 때 사용하십시오 .)

개인적으로 말하면, (a) 여분의 색인이 문제이고, (b) 그것을 제거하는 것이 해결책이라는 것을 증명할 수있을 때까지는 그대로 두겠습니다.

해당 테이블에서 유일하게 (그리고 약간만 더 나쁘게) 수행되는 쿼리 유형은 KeyColumn 값 범위를 요청하는 쿼리 유형입니다. 현재 해당 쿼리는 PK 전체에서 인덱스 검색을 통해 가장 잘 제공됩니다.

이 테이블을 참조하는 테이블에 대한 참조 무결성 검사 비용은 더 높을 것입니다 (다소 약간 더 높음).

nullable 측면을 처리하는 한 인덱스 하나만으로도 충분합니다.

그것이 내 DB라면 아마도 단일 고유 인덱스로 갈 것입니다. 다른 모든 것은 동일합니다.

내가 아는 한 기본 키에 포함 열을 추가 할 수는 없습니다.

KeyColumn에 클러스터형 인덱스가있는 경우 클러스터형 인덱스이므로 다른 모든 열은 암시 적으로 '덮어집니다'. 따라서 KeyColumn에 다른 인덱스를 추가하여 아무것도 얻지 못합니다. 실제로 인서트 속도를 늦추고 더 많은 공간을 사용합니다.

클러스터 된 인덱스는 인덱스가 아니기 때문에 인덱스 순서대로 테이블의 행을 저장하는 명령 일뿐입니다. 그리고 기본 키로 행을 fou 으면 다른 모든 열이 있습니다.