SQL 2005 : 키, 색인 및 제약 질문

Question

SQL, SQL 2005의 키, 인덱스 및 제약 조건에 대한 일련의 질문이 있습니다. 나는 약 4 년 동안 SQL과 함께 일해 왔지만이 주제에 대한 결정적인 답변을 얻을 수 없었으며 블로그 게시물 등에 항상 모순되는 정보가 있습니다. 제가 작성하고 사용하는 대부분의 시간 테이블은 ID 열이 있습니다. 기본 키이며 다른 테이블은 외국 키를 통해이를 가리 킵니다.

조인 테이블을 사용하면 신원이없고 외래 키 열에 복합 기본 키를 만듭니다. 다음은 내 현재 신념에 대한 일련의 진술입니다.

그래서 여기에 간다 :

내가 이해할 때 클러스터링 된 인덱스와 비 클러스터 인덱스의 차이 (고유 여부에 관계없이)는 클러스터 된 인덱스가 테이블에서 데이터의 물리적 순서에 영향을 미치는 반면 (따라서 테이블에만있을 수 있음). 클러스터되지 않은 인덱스는 트리 데이터 구조를 구축합니다. 인덱스를 만들 때 왜 클러스터링 대 비 클러스터에 관심을 가져야합니까? 언제 하나를 사용해야합니까? 트리가 "재건"되어야하므로 삽입 및 삭제가 클러스터되지 않은 인덱스로 느리다고 들었습니다. 클러스터 된 인덱스가 이런 식으로 성능에 영향을 미치지 않습니까?

기본 키는 실제로 고유 한 클러스터 된 인덱스 일뿐입니다 (클러스터링해야합니까?). 기본 키와 클러스터 된 고유 인덱스의 특별한 점은 무엇입니까?

나는 또한 제약 조건을 보았지만, 나는 그것들을 사용하지 않았거나 실제로 그들을 본 적이 없다. 제약 조건의 목적은 데이터 무결성을 시행하는 반면 인덱스는 성능을 목표로한다는 것입니다. 또한 제약 조건은 어쨌든 인덱스로 구현되므로 "동일합니다"라는 것을 읽었습니다. 이것은 나에게 옳지 않은 소리가 아닙니다. 제약 조건은 인덱스와 어떻게 다릅니 까?

Answer 1

클러스터 된 인덱스 올바르게 말하면 테이블의 데이터가 물리적으로 저장되는 방법에 대한 정의, 즉 클러스터링 키를 사용하여 B- 트리를 정렬하고 잎 수준에 데이터가 있습니다.

비 클러스터 인덱스 반면에 잎 수준에서 클러스터링 키 만있는 별도의 트리 구조 (또는 테이블이 힙 인 경우 RID)가 있습니다. 즉, 클러스터되지 않은 인덱스를 사용하면 클러스터 된 인덱스를 사용해야합니다. 다른 열을 얻으려면 (요청에 클러스터되지 않은 인덱스가 완전히 커버되지 않는 한, 비 클러스터 인덱스 키 열을 구성하는 열만 요청하면 발생할 수 있습니다).

언제 하나 또는 다른 것을 사용해야합니까? 글쎄, 당신은 하나의 클러스터 인덱스 만 가질 수 있기 때문에 가장 의미가있는 열에서 정의하십시오. 비 클러스터 인덱스는 덜 자주 사용되는 열에서 정의되어야합니다.

인덱스 키를 변경하는 성능, 인서트 또는 업데이트와 관련하여 페이지 분할이 발생할 수 있으므로 클러스터가 아닌 인덱스에서 클러스트되는지 여부에 관계없이 항상 고통 스럽습니다. 잎 수준에 더 많은 데이터가 있기 때문에 더 아파요). 따라서 일반적인 규칙은 인덱스 키를 변경하지 않고 새로운 값을 삽입하여 시퀀스가되도록하는 것입니다. 그렇지 않으면 조각화가 발생하고 정기적으로 인덱스를 재건해야합니다.

마지막으로, 제약과 관련하여 정의에 따라 인덱스와 관련이 없지만 SQL Server는 인덱스를 사용하여이를 구현하도록 선택했습니다. 예를 들어 현재 고유 한 제약 조건은 색인으로 구현되지만 향후 버전에서 변경 될 수 있습니다 (의심의 여지가 있지만). 인덱스 유형 (클러스터링 여부)은 귀하에게 달려 있습니다. 단 하나의 클러스터 인덱스 만 가질 수 있음을 기억하십시오.

이 유형에 대한 질문이 더 있으면 읽는 것이 좋습니다. 이 책, 이 주제를 깊이 다루는 것.

Answer 2

에 대한 당신의 가정 클러스터링 대 비 클러스터 꽤 좋습니다

또한 기본 키는 Null Nulliquenes를 시행하는 것처럼 보이지만 고유 인덱스는 Null이 아닌 경우에 시행하지 않습니다. 기본 대 독특한

Answer 3

그만큼 기본 키 관계형 데이터베이스 이론의 논리적 개념입니다. 행을 고유하게 식별하도록 설계된 핵심 (일반적으로 색인)입니다. 따라서 독특해야하며 무효가 될 수 없습니다.

그만큼 클러스터링 키 SQL Server의 스토리지-물리적 개념입니다. 조회 등에 사용하는 것이 아니라 테이블에서 데이터의 물리적 구조를 정의하는 특수 인덱스입니다. 서유럽 문화의 인쇄 된 전화 번호부 (아이슬란드 제외)에서 클러스터 된 인덱스는 "마지막 이름, FirstName"입니다.

클러스터링 인덱스는 물리적 데이터 레이아웃을 정의하기 때문에 그 중 하나만 가질 수 있습니다 (또는 권장하지 않음).

클러스터링 키에 대한 요구 사항은 다음과 같습니다.

• 고유해야합니다 (그렇지 않은 경우 SQL Server는 4 바이트 "고유 한"을 추가합니다)
• 안정적이어야합니다 (절대 변하지 않음)
• 가능한 한 작아야합니다 (int는 최고입니다)
• 계속 증가해야합니다 (생각 : 정체성)

SQL Server는 기본 키를 기본적으로 클러스터링 키로 만듭니다. 그러나 필요한 경우 변경할 수 있습니다. 또한 클러스터링 키를 구성하는 열은 테이블의 각각 비 클러스터 된 인덱스의 각 항목에 추가됩니다. 따라서 클러스터링 키를 최대한 작게 유지하려고합니다. 클러스터링 키가 "책갈피 조회"를 수행하는 데 사용되기 때문입니다. 비 클러스터 인덱스 (예 : 사회 보장 번호의 사람)에서 항목을 찾으면 이제 전체 데이터 행을 가져와야합니다. 자세한 내용은 조회를 수행해야하며 클러스터링 키가 사용됩니다.

좋은 또는 유용한 클러스터링 및/또는 기본 키를 만드는 것에 대한 훌륭한 논쟁이 있습니다. 여기에 대해 읽을 수있는 몇 가지 훌륭한 블로그 게시물이 있습니다.

• Kimberly Tripp의 인덱싱 블로그 게시물은 모두 읽어야합니다.
• 기본 키 및/또는 클러스터링 키로 안내
• 클러스터 된 색인 토론은 계속됩니다 ....

마크

Answer 4

몇 가지 질문이 있습니다. 나는 그들 중 일부를 분해 할 것이다 :

인덱스를 만들 때 왜 클러스터링 대 비 클러스터에 관심을 가져야합니까?

때로는 행이 어떻게 정리되는지 신경 쓰지 않습니다. 데이터와 사용 방법에 따라 다릅니다. 예를 들어, 기본 키 인 경우 uniqueidentifier, 당신은 그것을 원하지 않을 수도 있습니다 CLUSTERED, 안내 값은 본질적으로 무작위이기 때문에. 이렇게하면 SQL이 테이블 전체에 행을 무작위로 삽입하여 페이지 분할이 발생하여 성능이 떨어집니다. 기본 키 값이 항상 순차적으로 증가하는 경우 (int IDENTITY 예를 들어), 당신은 아마도 그것을 원할 것입니다 CLUSTERED, 그래서 당신의 테이블은 항상 마지막에 자랍니다.

주요 키는입니다 CLUSTERED 기본적으로 대부분의 경우 걱정할 필요가 없습니다.

트리가 "재건"되어야하므로 삽입 및 삭제가 클러스터되지 않은 인덱스로 느리다고 들었습니다. 클러스터 된 인덱스가 이런 식으로 성능에 영향을 미치지 않습니까?

실제로 반대는 사실 일 수 있습니다. NONCLUSTERED 인덱스는 별도의 데이터 구조로 유지되지만 구조는 "재건"할 필요없이 일부 수정을 허용하도록 설계되었습니다. 인덱스가 처음 작성되면 FILLFACTOR, 인덱스의 각 페이지에 얼마나 많은 여유 공간을 남길 수 있는지 지정합니다. 이를 통해 페이지 분할이 필요하기 전에 인덱스가 일부 수정을 견딜 수 있습니다. 페이지 분할이 발생하더라도 전체 색인이 아닌 인접 페이지에만 영향을 미칩니다.

동일한 동작이 적용됩니다 CLUSTERED 색인이지만 그 이후로 CLUSTERED 인덱스는 실제 테이블 데이터를 저장하고 인덱스의 페이지 분할 작업이 전체 행을 이동해야 할 수 있기 때문에 훨씬 비쌀 수 있습니다 (주요 열 및 ROWID 안에 NONCLUSTERED 인덱스).

다음 MSDN 페이지에 대해 이야기합니다 FILLFACTOR 및 페이지 분할 :http://msdn.microsoft.com/en-us/library/aa933139(sql.80).aspx

기본 키와 클러스터 된 고유 인덱스의 특별한 점은 무엇입니까? 제약 조건은 인덱스와 어떻게 다릅니 까?

이 두 가지 모두에 대해 나는 그것이 당신의 의도를 선언하는 것에 관한 것이라고 생각합니다. 당신이 무언가를 부를 때 PRIMARY KEY 주어진 행을 식별하는 기본 방법이라고 선언합니다. a PRIMARY KEY 물리적으로 a와 다릅니다 CLUSTERED UNIQUE INDEX? 잘 모르겠습니다. 동작은 본질적으로 동일하지만 귀하의 의도는 데이터베이스에서 작업하는 사람에게는 명확하지 않을 수 있습니다.

제약과 관련하여 많은 유형의 제약이 있습니다. a UNIQUE CONSTRAINT, 그와 UNIQUE INDEX, 의도를 선언하는 것 외에. 다른 유형의 인덱스에 직접 매핑되지 않는 다른 유형의 제약 조건이 있습니다. CHECK 제약, DEFAULT 제약 및 FOREIGN KEY 제약.

Answer 5

나는 이것에 깊이있게 대답 할 시간이 없으므로 여기 내 머리 위의 정보가 있습니다.

당신은 클러스터 된 인덱스에 대해 옳습니다. 클러스터 된 인덱스의 정렬 순서에 따라 물리적 데이터를 재정렬합니다. 범위 바운드 쿼리 (예 : 날짜 간)에 특별히 클러스터 인덱스를 사용할 수 있습니다.

PK는 기본적으로 클러스터링되었지만 그럴 필요는 없습니다. 그것은 단지 기본 설정 일뿐입니다. PK는 행의 UID가되어야합니다.

제약 조건은 인덱스 (예 : 고유 한 제약 조건)로 구현 될 수 있지만 기본값으로도 구현할 수도 있습니다.