답변:
독특 할 필요 는 없지만 확실히 권장됩니다.
고유하지 않은 열에 CI를 생성하려는 시나리오는 아직 발생하지 않았습니다.
고유하지 않은 열에 CI 를 생성 하면 어떻게 되나요?
클러스터형 인덱스가 고유 인덱스가 아닌 경우 SQL Server는 고유 자라는 내부 생성 값을 추가하여 중복 키를 고유하게 만듭니다.
이로 인해 성능이 저하됩니까?
고유자를 추가하면 계산 및 저장에 약간의 오버 헤드가 추가됩니다.
이 오버 헤드가 눈에 띄는 지 여부는 여러 요인에 따라 다릅니다.
Remus가 의견에서 지적한대로 편집 하면 고유하지 않은 CI를 만드는 것이 합리적인 선택이 될 수있는 사용 사례가 있습니다. 그러한 시나리오 중 하나를 만나지 않은 나는 단지 내 자신의 노출이나 능력이 부족하다는 것을 보여줄뿐입니다 (선택을 선택하십시오).
인덱싱의 여왕 Kimberly Tripp이이 주제에 대해 뭐라고 말했는지 확인하고 싶습니다.
몇 가지 이유로 클러스터링 키에 대한 권장 사항부터 시작하겠습니다. 첫째, 쉬운 결정이고 둘째,이 결정을 일찍 내리면 일부 유형의 조각화를 사전에 방지하는 데 도움이됩니다. 특정 유형의 기본 테이블 조각화를 방지 할 수있는 경우 일부 유지 관리 작업을 최소화 할 수 있습니다 (일부, SQL Server 2000 및 그보다 적은 경우 SQL Server 2005). 좋아, 나중에 재 구축에 대해 알아볼 게 .....
클러스터링 키에서 찾은 주요 사항부터 시작하겠습니다.
* Unique
* Narrow
* Static
왜 독특한가? 클러스터링 키 (있는 경우)가 모든 비 클러스터형 인덱스의 조회 키로 사용되기 때문에 클러스터링 키는 고유해야합니다. 예를 들어 책 뒷면의 색인을 살펴 보겠습니다. 색인 항목이 가리키는 데이터를 찾아야하는 경우 해당 항목 (색인 항목)은 고유해야합니다. 그렇지 않은 경우에는 어떤 색인 항목이 찾고 있는지 확인합니다. ? 따라서 클러스터형 인덱스를 만들 때 고유해야합니다. 그러나 SQL Server에서는 고유 한 열에 클러스터링 키를 만들 필요가 없습니다. 원하는 열에 만들 수 있습니다. 내부적으로 클러스터링 키가 고유하지 않은 경우 SQL Server는 데이터에 4 바이트 정수를 추가하여이를 "고유 화"합니다. 따라서 클러스터형 인덱스가 고유하지 않은 항목에 생성되면 인덱스 생성시 추가 오버 헤드가있을뿐만 아니라 낭비되는 디스크 공간이 있습니다.
newsequentialid()거의 순차적 인 GUID를 얻기 위해 사용한다고 말합니다 . 하지만 예 : 고유 한 ID 를 추가 하면 (항상 INT IDENTITY를 선호합니다) 해당 값을 가지고 있고이를 사용할 수 있습니다 (예 : FK 관계 설정). SQL Server에 추가 된 고유 요소는 사용자에게 표시되지 않으므로 사용할 수없는 오버 헤드 일뿐입니다.
클러스터형 인덱스는 고유해야합니까?
그렇지 않으며 그렇지 않은 경우 더 나은 때가 있습니다.
반 무작위, 고유 EmployeeId 및 각 직원에 대한 DepartmentId가있는 테이블을 고려하십시오. select 문이 다음과 같은 경우
SELECT * FROM EmployeeTable WHERE DepartmentId=%DepartmentValue%
그러면 DepartmentId고유 인덱스가 아니더라도 (또는 특히) 클러스터형 인덱스 인 경우 성능에 가장 좋습니다 (주어진 DepartmentId 내의 모든 레코드가 클러스터링되도록하기 때문에 성능에 가장 적합합니다).
참고 문헌이 있습니까?
거기에 클러스터 된 인덱스 디자인 지침 말한다 예는,
몇 가지 예외를 제외하고 모든 테이블에는 다음을 제공하는 열 또는 열에 정의 된 클러스터형 인덱스가 있어야합니다.
- 자주 사용하는 쿼리에 사용할 수 있습니다.
- 높은 수준의 고유성을 제공합니다.
- 범위 쿼리에 사용할 수 있습니다.
예를 들어 "높은 수준의 고유성"에 대한 나의 이해는 대부분의 쿼리가 주어진 도시 내의 레코드를 선택하려는 경우 클러스터 된 인덱스로 "국가"를 선택하는 것이 좋지 않다는 것입니다.