SQL Server 2000에서 '증분 키를 기반으로 클러스터형 인덱스를 만들지 마십시오'는 잘못된 생각입니까?


22

우리의 데이터베이스는 많은 테이블로 구성되어 있으며, 대부분은 정수 대리 키를 기본 키로 사용합니다. 이러한 기본 키의 약 절반은 ID 열에 있습니다.

데이터베이스 개발은 SQL Server 6.0 시절에 시작되었습니다.

처음부터 따라온 규칙 중 하나는 다음과 같습니다. 이 색인 최적화 팁 에서 볼 수 있듯이 증분 키를 기반으로 클러스터형 색인 작성을 피하십시오 입니다.

이제 SQL Server 2005와 SQL Server 2008을 사용하여 상황이 바뀌 었다는 강한 인상을 받았습니다. 한편,이 기본 키 열은 테이블의 클러스터 된 인덱스에 대한 첫 번째 후보입니다.

답변:


34

신화는 행 수준 잠금 을 추가 한 SQL Server 6.5 이전으로 돌아갑니다. . 그리고 Kalen Delaney가 암시했습니다 .

데이터 페이지 사용의 "핫스팟"과 관련이 있으며 삽입 된 행 대신 전체 2k 페이지 (SQL Server 7 이상에서 8k 페이지 사용)가 잠겼다는 사실 편집, 2012 년 2 월

Kimberly L. Tripp의 권위있는 기사를 찾았습니다.

"클러스터형 인덱스 토론이 계속됩니다 ..."

핫스팟은 페이지 수준 잠금으로 인해 SQL Server 7.0 이전에 피하려고 시도한 것입니다 (핫스팟이라는 용어는 부정적인 용어가되었습니다). 실제로 부정적인 용어 일 필요는 없습니다. 그러나 저장소 엔진은 SQL Server 7.0에서 다시 설계 / 재 설계되어 실제 행 수준 잠금이 포함되므로 핫스팟을 피하기위한 이러한 동기는 더 이상 존재하지 않습니다.

편집, 2013 년 5 월

lucky7_2000의 답변에있는 링크는 핫스팟이 존재할 수 있으며 문제를 일으키는 것으로 보입니다. 그러나이 기사에서는 TranTime에서 고유하지 않은 클러스터형 인덱스를 사용합니다. 이를 위해서는 단일화 기가 추가되어야합니다. 색인이 아닌 단조 증가 (너무 넓음) 의미합니다. 해당 답변의 링크가이 답변 또는 내 링크와 모순되지 않습니다

개인적 으로, 클러스터 된 PK로서 IDENTITY 열이 큰 테이블에 초당 수만 행을 삽입 한 데이터베이스에 대해 살펴 보았습니다 .


23

요컨대 최신 SQL Server 버전에서는 요즘에는 ID 열의 클러스터 키가 선호되는 옵션입니다.


짧고 간단해서 요점은 +1입니다. 좋은 정보가 풍부하므로 SQLSkill에 대한 링크를 확인하십시오.
— AndrewSQL

12
이것은 명령처럼 들립니다. 왜 우리가해야하는지에 대한 설명이나 논리가 없습니다 .
— gbn

명령처럼 들릴뿐만 아니라 잘못되었습니다. 순차 키를 사용하는 경우 매우 많은 양의 삽입 / 초를 사용하는 데이터베이스는 핫스팟 문제가 발생합니다.
— Thomas Kejser

1
나는 선호했다, 필수는 아닙니다. 전 세계 데이터베이스의 98 %를 구성하는 일반 응용 프로그램의 경우 ID 열의 클러스터 키가 제대로 작동합니다.
— mrdenny

10

Kimberly Tripp에는이 주제에 관한 환상적인 블로그 게시물이 있습니다. 나는 변역 할 수는 있지만, 믿어 라. 나는 그것을 정의하지 않을 것이다. 읽어보세요. http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increasing-clustering-key-the-Clustered-Index-Debateagain!.aspx

그 동안 클러스터링 키 주제에 대한 다른 게시물을 확인하십시오. 그녀의 사이트에서 얻을 수있는 풍부한 지식이 있습니다.


4

이 게시물을 확인하십시오 :

http://blogs.msdn.com/b/sqlserverfaq/archive/2010/05/27/monotonically-increasing-clustered-index-keys-can-cause-latch-contention.aspx

증분 키를 기반으로 클러스터형 인덱스를 생성하면 성능에 좋지 않은 핫스팟이 생성 될 수 있습니다.


1
해당 링크를 제공 한 +1 흥미로운 힌트가 있습니다. 그러나 주어진 시나리오를 tblTransactions (TranTime) 또는 다른 대안으로 클러스터되지 않은 인덱스 cidx_trantime을 사용하는 시나리오와 비교하면 결과가 훨씬 더 설득력이 있다고 생각합니다. 많은 양의 데이터를 생성 할 때 데이터를 검색하는 효율적인 방법이 있어야한다는 것을 기억하십시오. 모든 것을 힙에 버릴 수는 없습니다.
— bernd_k

@bernd_k : 이것은 좋지 않은 예제 링크입니다. 자식 테이블은 내부 uniquifier 필요로하는 나쁜 고유하지 않은 클러스터 키가
— GBN

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.