2011-03-25 4 views
2

안녕하세요 저는 SQL에 익숙하지 않습니다. 누군가가 저에게 같은 칼럼에 클러스터 된 인덱스와 클러스터되지 않은 인덱스를 사용할 수 있는지 궁금합니다. 내 작업에서 일부 테이블 스크립트를 찾고 있었지만, 한 컬럼에 클러스터 된 인덱스와 클러스터되지 않은 인덱스를 모두 사용하는 것이 무엇인지 이해하지 못했습니다. ID 열과 데이터베이스의 모든 테이블에 있습니다.INDEX 질문

+0

SQL Server에 대해 이야기 할 때 우리가 맞습니까? –

+0

예 SQL, thanks ... – Programmer

+1

'SQL'은 단지 ** 구조화 된 쿼리 언어 ** - ** 제품 **이 아닙니다 - 데이터베이스 시스템이 없습니다. 당신이 말하는 것은 Microsoft의 ** SQL Server ** - 구체적인 데이터베이스 제품입니다. –

답변

2

단순한 용어로 CLUSTERED 인덱스와 NON CLUSTERED INDEX의 차이점은 CLUSTERED 인덱스는 인덱싱 된 필드의 값을 기반으로 테이블의 레코드를 물리적으로 정렬하는 반면 NON CLUSTERED 인덱스는 논리적 인덱싱 된 필드의 값을 기반으로 테이블의 레코드 순서 지정 이 논리적 정렬은 테이블의 값 통계 분포를 기반으로 SQL 데이터베이스 엔진에 의해 결정됩니다.

또 다른 중요한 차이점은 테이블의 경우 CLUSTERED 인덱스를 하나만 가질 수 있다는 것입니다 (테이블에 저장된 데이터의 물리적 순서 지정). 동일한 테이블에서 여러 필드에 여러 가지 비 CLUSTERED 인덱스를 가질 수 있습니다.

물론 테이블의 동일한 필드에 CLUSTERED 및 NON CLUSTERED 인덱스를 둘 수 있습니다. 일반적으로 CLUSTERED 인덱스는 데이터를 순차적으로 액세스하는 것이 좋고 NON CLUSTERED 인덱스는 임의적으로 최적화 할 수 있으므로 유용합니다. SQL 데이터베이스 엔진에 의한 데이터 액세스. 이렇게하면 동일한 열에 CLUSTERED 및 NON CLUSTERED 인덱스를 조합하여 인덱싱 된 필드의 값을 기반으로 검색 할 때 해당 테이블의 레코드에 대한 액세스가 최적화됩니다.

+0

이것은 같은 열에 NCI와 CI가있는 이유를 설명하지 않습니다. 2 인덱스의 비 리프 레벨 페이지는 거의 동일하므로 특정 ID로 찾는 경우 임의 액세스에 특별한 이점이 없습니다 (특히 NCI가 행 키 지정자로 CI 키를 사용하므로 CI가 * * 아직도 ** 횡단되어야합니다!). 또한 이들 중 어느 것도 물리적 순서 (단편화)에 있지는 않습니다. 둘 다 논리적 순서로 만 다음 및 이전 페이지가 페이지 머리글의 필드로 표시됩니다. –

+0

@Martin NCI/CI의 경우 단일 ID로 단일 행을 조회 할 때 약간의 차이가 있습니다. 이 경우 ID 열이 데이터베이스의 모든 테이블에있는 경우 잘못되었거나 잘못되었을 수 있습니다. 이러한 ID가 동일한 것을 나타낼 지 여부를 아는 것은 어렵습니다. 코드 냄새처럼 들리지만 정당한 이유가 있습니다. OP가 NCI가 열을 포함한다는 것을 간과 한 경우 (그리고 특정 쿼리에 대해 다루기 시작한 경우) 어떻게됩니까? 그러면 NCI 스캔이이 테이블의 테이블 스캔보다 선호 될 것입니다. –

+0

@Cade - 네, 맞습니다. 원래 댓글에 오류가 있음을 확인했습니다. 비 리프 페이지는 물론 CI가 아마 페이지가 더 많아지기 때문에 트리가 더 넓고 깊어 지지만 NCI의 검색은 CI를 탐색해야합니다. –

4

클러스터 된 인덱스는 실제로 인덱스가 아닙니다. 즉, 키에 따라 트리에서 구성된 모든 데이터입니다.

클러스터되지 않은 인덱스는 추가로 포함 된 열과 필요한 경우 데이터 행을 가져 오는 데 필요한 책갈피가있는 트리의 키에 불과합니다. 데이터 자체는 클러스터 된 인덱스 또는 힙에 저장 될 수 있습니다. 그리고 비 클러스터형 인덱스가 많이있을 수 있지만 데이터 저장을 선택하는 유일한 방법은 분명합니다.

특정 쿼리의 성능을 위해 힙 (또는 인덱스가 포함되어 있으므로 중요하지 않은 항목)에 적용되는 클러스터되지 않은 인덱스는 클러스터 된 인덱스보다 성능이 뛰어날 수 있습니다. 클러스터 된 인덱스 찾기/검색은 더 많은 데이터를 읽고 버리고 페이지 당 더 적은 행을 채우는 반면 페이지 당 행 수 있고 행에서 데이터를 가져 오기 위해 책갈피 조회가 필요하지 않습니다.

일반적으로 클러스터 된 인덱스가 필요하고 클러스터링 키는 좁고 정적이며 증가하며 고유해야합니다.

그러나 쿼리 성능을 위해서는 클러스터되지 않은 인덱스를보고 원하는대로 올바른 방향으로 정렬 순서가있는 선택 항목을 갖고 싶습니다.

+0

단일 ID 열에 NCI와 CI가있는 이유는 아직까지 사용 사례가 없습니다. 나는'id'에 대한 좁은 인덱스가 세미 조인이나 외래 키 제약 조건과 같은 특정 종류의 쿼리에 유용 할 수 있다고 생각할 수 있습니다. 다른 유스 케이스는 실제로 생각할 수 없습니까? –

+0

@Martin 단일 ID 및 포함되지 않은 열이있는 NCI는 존재 확인에 더 빠르며 ID가있는 CI보다 빠릅니다 (테이블이 비교적 넓다고 가정하면 더 많은 데이터를 페이지 당 맞출 수 있기 때문입니다). 그러나 맞습니다.이 시나리오는 ID가 외래 키인 경우에만 유용합니다. 예를 들어 특정 기준과 일치하는 행에 대해 FK가 다른 테이블에 유용합니다. 일반적으로 커버하는 NCI가 선호 될 것입니다. 이 경우 색인이 덮여 있기 때문에 책갈피 및 CI 선택은 무의미합니다. 당신은 CI를 가져야 만합니다. 그러나 읽기 권한을 위해 의존하지 마십시오. –