클러스터된 인덱스 및 비클러스터된 인덱스는 실제로 무엇을 의미합니까?
저는 DB에 대한 노출이 제한적이고 DB를 애플리케이션 프로그래머로만 사용해 왔습니다. i i i i i 에 대해 알고 싶다Clustered ★★★★★★★★★★★★★★★★★」Non clustered indexes검색해보니 다음과 같더군요.
클러스터된 인덱스는 테이블의 레코드가 물리적으로 저장되는 방식을 정렬하는 특수한 유형의 인덱스입니다.따라서 테이블에는 클러스터된 인덱스가 하나만 있을 수 있습니다.클러스터된 인덱스의 리프 노드에는 데이터 페이지가 포함됩니다.비클러스터형 인덱스는 인덱스의 논리 순서가 Disk 행의 실제 저장 순서와 일치하지 않는 특수한 유형의 인덱스입니다.비클러스터 인덱스의 리프 노드가 데이터 페이지로 구성되어 있지 않습니다.대신 리프 노드에는 인덱스 행이 포함됩니다.
SO에서 발견한 것은 클러스터화된 인덱스와 비클러스터화된 인덱스의 차이점은 무엇입니까?
누가 이것을 쉬운 영어로 설명해 줄 수 있나요?
클러스터된 인덱스의 경우 행은 인덱스와 동일한 순서로 디스크에 물리적으로 저장됩니다.따라서 클러스터된 인덱스는 하나만 있을 수 있습니다.
클러스터되지 않은 인덱스의 경우 물리적 행에 대한 포인터가 있는 두 번째 목록이 있습니다.새 인덱스가 생성될 때마다 새 레코드를 작성하는 데 걸리는 시간이 늘어나지만 클러스터되지 않은 인덱스가 여러 개 있을 수 있습니다.
열을 모두 가져오려면 일반적으로 클러스터된 인덱스에서 읽는 것이 더 빠릅니다.먼저 인덱스로 이동한 다음 테이블로 이동할 필요가 없습니다.
데이터를 다시 정렬해야 하는 경우 클러스터된 인덱스가 있는 테이블에 쓰는 속도가 느려질 수 있습니다.
클러스터된 색인은 데이터베이스에 실제로 서로 가까운 값을 디스크에 저장하도록 지시하는 것을 의미합니다.이는 일정 범위의 클러스터화된 인덱스 값에 해당하는 레코드를 신속하게 스캔/검색하는 장점이 있다.
예를 들어, Customer와 Order라는 두 개의 테이블이 있습니다.
Customer
----------
ID
Name
Address
Order
----------
ID
CustomerID
Price
특정 고객의 모든 주문을 신속하게 가져오려면 "고객"에서 클러스터화된 인덱스를 생성할 수 있습니다.[ Order ]테이블의 [ID]컬럼을 표시합니다.이와 같이, 같은 고객과의 사이에 기록이 남습니다.ID는 물리적으로 디스크에 서로 가까이(클러스터됨) 저장되므로 검색 속도가 빨라집니다.
추신: 고객지수ID는 고유하지 않으므로 인덱스를 "unique"하기 위해 두 번째 필드를 추가하거나 데이터베이스가 대신 처리하도록 해야 합니다. 그러나 이는 다른 이야기입니다.
여러 인덱스에 대해서.테이블당 클러스터된 인덱스는 데이터가 물리적으로 배열되는 방법을 정의하기 때문에 하나만 가질 수 있습니다.만약 여러분이 유추를 원한다면, 테이블이 많이 있는 큰 방을 상상해 보세요.이러한 테이블은 여러 행을 형성하기 위해 배치할 수도 있고 모두 하나로 모아 큰 회의 테이블을 형성할 수도 있습니다.단, 동시에 양쪽 모두 할 수는 없습니다.테이블에는 다른 인덱스가 있을 수 있으며 클러스터된 인덱스의 엔트리를 가리킵니다.이 엔트리는 최종적으로 실제 데이터를 찾을 위치를 나타냅니다.
SQL Server에서 행 지향 저장소는 클러스터된 인덱스와 비클러스터된 인덱스를 모두 B 트리로 구성합니다.
(이미지 소스)
클러스터된 인덱스와 클러스터되지 않은 인덱스의 주요 차이점은 클러스터된 인덱스의 리프 수준이 테이블이라는 것입니다.여기에는 두 가지 의미가 있습니다.
- 클러스터된 인덱스 리프 페이지의 행에는 항상 테이블의 각(희박하지 않은) 열에 대한 내용(값 또는 실제 값에 대한 포인터)이 포함됩니다.
- 클러스터된 인덱스는 테이블의 주 복사본입니다.
않은 을 .INCLUDE(SQL Server 2005 이후) 모든 비키 컬럼을 명시적으로 포함하지만 그것들은 세컨더리 표현이며 항상 (테이블 자체) 주위에 다른 데이터 복사본이 있습니다.
CREATE TABLE T
(
A INT,
B INT,
C INT,
D INT
)
CREATE UNIQUE CLUSTERED INDEX ci ON T(A, B)
CREATE UNIQUE NONCLUSTERED INDEX nci ON T(A, B) INCLUDE (C, D)
위의 두 인덱스는 거의 동일합니다. 컬럼의 하는 상위 와 함께A, B및 다음을 포함하는 리프 레벨 페이지A, B, C, D
데이터 행 자체는 하나의 순서로만 정렬할 수 있으므로 테이블당 클러스터된 인덱스는 하나만 있을 수 있습니다.
위의 SQL Server 온라인 서적 인용문은 많은 혼란을 일으킨다.
내 생각에, 그것은 훨씬 더 좋은 표현일 것 같다.
클러스터된 인덱스의 리프 수준 행은 테이블 행이므로 테이블당 클러스터된 인덱스는 하나만 있을 수 있습니다.
이 책의 온라인 인용문은 정확하지 않지만 클러스터되지 않은 인덱스와 클러스터되지 않은 인덱스의 "정렬"은 물리적인 것이 아니라 논리적인 것임을 명확히 해야 합니다.링크된 목록을 따라 리프 레벨의 페이지를 읽고 페이지의 행을 슬롯 배열 순서로 읽으면 인덱스 행을 정렬된 순서로 읽지만 페이지가 물리적으로 정렬되지 않을 수 있습니다.클러스터된 인덱스의 경우 행이 항상 인덱스 키와 같은 순서로 디스크에 물리적으로 저장된다는 일반적인 믿음은 잘못된 것입니다.
이것은 터무니없는 실행이 될 것이다.예를 들어, 4GB 테이블 중간에 행을 삽입하는 경우 SQL Server는 새로 삽입된 행을 위한 공간을 확보하기 위해 2GB의 데이터를 파일에 복사할 필요가 없습니다.
대신 페이지 분할이 발생합니다. 않은 인덱스의 의 각 가 .File: Page논리 키 순서로 다음 페이지와 이전 페이지의 )를 표시합니다.이러한 페이지는 연속 페이지 또는 키 순서일 필요는 없습니다.
들어 은 """일 수 .1:2000 <-> 1:157 <-> 1:7053
페이지 분할이 발생하면 파일 그룹 내 임의의 위치에서 새 페이지가 할당됩니다(혼합된 익스텐트, 작은 테이블 또는 해당 개체에 속하는 비어 있지 않은 균일한 익스텐트 또는 새로 할당된 균일한 익스텐트).파일 그룹에 두 개 이상의 파일이 포함되어 있는 경우 동일한 파일에 존재하지 않을 수도 있습니다.
논리적 순서와 인접성이 이상적인 물리적 버전과 다른 정도는 논리적 단편화 정도입니다.
단일 파일로 새로 만든 데이터베이스에서 다음을 실행했습니다.
CREATE TABLE T
(
X TINYINT NOT NULL,
Y CHAR(3000) NULL
);
CREATE CLUSTERED INDEX ix
ON T(X);
GO
--Insert 100 rows with values 1 - 100 in random order
DECLARE @C1 AS CURSOR,
@X AS INT
SET @C1 = CURSOR FAST_FORWARD
FOR SELECT number
FROM master..spt_values
WHERE type = 'P'
AND number BETWEEN 1 AND 100
ORDER BY CRYPT_GEN_RANDOM(4)
OPEN @C1;
FETCH NEXT FROM @C1 INTO @X;
WHILE @@FETCH_STATUS = 0
BEGIN
INSERT INTO T (X)
VALUES (@X);
FETCH NEXT FROM @C1 INTO @X;
END
다음으로 페이지 레이아웃을 확인했습니다.
SELECT page_id,
X,
geometry::Point(page_id, X, 0).STBuffer(1)
FROM T
CROSS APPLY sys.fn_PhysLocCracker( %% physloc %% )
ORDER BY page_id
결과는 엉망이었다.키 순서의 첫 번째 행(값 1 - 아래 화살표로 강조 표시됨)은 거의 마지막 물리적 페이지에 있습니다.
논리적 순서와 물리적 순서 간의 상관 관계를 증가시키기 위해 인덱스를 재구성하거나 재구성하여 단편화를 줄이거나 제거할 수 있습니다.
실행 후
ALTER INDEX ix ON T REBUILD;
나는 다음과 같은 것을 얻었다.
테이블에 클러스터된 인덱스가 없는 경우 힙이라고 합니다.
클러스터되지 않은 인덱스는 힙 또는 클러스터된 인덱스에 빌드할 수 있습니다.기본 테이블로 돌아가는 행 로케이터가 항상 포함되어 있습니다.힙의 경우 이는 물리행 식별자(rid)이며 3개의 컴포넌트(파일:페이지: 슬롯).클러스터된 인덱스의 경우 행 로케이터는 논리적입니다(클러스터된 인덱스 키).
또는 NCI 키열 중 INCLUDE도 추가되지 않습니다 -d컬럼은 추가되지 않습니다.그렇지 않으면 누락된 CI 키 열이 NCI에 자동으로 추가됩니다.
SQL Server는 항상 키 열이 두 인덱스 유형 모두에 대해 고유하도록 합니다.그러나 고유하다고 선언되지 않은 인덱스에 대해 적용되는 메커니즘은 두 인덱스 유형에 따라 다릅니다.
는 ""를 .uniquifier기존 행을 복제하는 키 값을 가진 행에 대해 추가됩니다.이것은 단지 오름차순 정수입니다.
고유한 SQL Server로 선언되지 않은 클러스터되지 않은 인덱스의 경우 행 로케이터를 클러스터되지 않은 인덱스 키에 자동으로 추가합니다.이는 실제로 중복된 행뿐만 아니라 모든 행에 적용됩니다.
클러스터된 명명법과 클러스터되지 않은 명명법은 열 저장소 인덱스에도 사용됩니다."SQL Server Column Stores 확장" 문서 상태
컬럼 스토어 데이터는 실제로 어떤 키에서도 "클러스터"되지 않지만 프라이머리 인덱스를 클러스터된 인덱스로 참조하는 기존 SQL Server 규칙을 유지하기로 결정했습니다.
이것은 매우 오래된 질문이라는 것을 알고 있습니다만, 저는 위의 훌륭한 답변을 설명하기 위해 유추해당 질문은 다음과 같습니다.
클러스터화된 인덱스
공공도서관으로 걸어 들어가면 모든 책이 특정한 순서로 배열되어 있다는 것을 알게 될 것이다.이는 책의 "클러스터된 색인"에 해당합니다.원하는 책의 DDS 번호가005.7565 F736s '책장'이라는 001-099(스택 끝에 있는 이 엔드캡 기호는 인덱스의 "중간 노드"에 해당합니다.) 후, 종 labelled labelled labelled labelled라고 하는 라벨이 붙어 있는 합니다.005.7450 - 005.7600그 후 지정된 DDS#의 책을 찾을 때까지 스캔하고, 그 시점에서 책을 찾을 수 있습니다.
비클러스터 인덱스
하지만 만약 당신이 책의 DDS 번호를 외우고 도서관에 오지 않았다면, 당신은 당신을 도와줄 두 번째 색인이 필요할 것이다.옛날에는 도서관 앞쪽에 "카드 카탈로그"로 알려진 멋진 서랍장을 발견할 수 있었다.그 안에는 수천 장의 3x5 카드가 들어 있었다. 각 책마다 하나씩 알파벳 순으로 정렬되어 있었다.이는 "비클러스터 인덱스"에 해당합니다.이러한 카드 카탈로그는 계층 구조로 구성되어 있기 때문에 각 드로어에 포함된 카드의 범위로 라벨이 붙여집니다( ).Ka - Kl예를 들어, "인증 노드"와 같습니다.다시 한 번, 책을 찾을 때까지 드릴인합니다. 그러나 이 경우 책을 찾으면(즉, "리프 노드") 책 자체가 아니라 클러스터된 색인에서 실제 책을 찾을 수 있는 색인 번호(DDS#)를 가진 카드만 갖게 됩니다.
물론 사서들이 모든 카드를 복사하고 별도의 카드 카탈로그에 다른 순서로 분류하는 것을 막을 수는 없을 것이다.(일반적으로 작성자 이름별로 정렬된 카탈로그와 제목별로 정렬된 카탈로그가 두 개 이상 있습니다.)기본적으로 이러한 "비클러스터" 인덱스는 원하는 만큼 가질 수 있습니다.
클러스터된 인덱스와 비클러스터된 인덱스의 특성을 아래에서 찾아보십시오.
클러스터된 인덱스
- 클러스터된 인덱스는 SQL 테이블의 행을 고유하게 식별하는 인덱스입니다.
- 각 테이블에는 클러스터된 인덱스가 1개만 있을 수 있습니다.
- 둘 이상의 열을 포함하는 클러스터된 인덱스를 생성할 수 있습니다.를 들면, '먹다'와 같이요.
create Index index_name(col1, col2, col.....). - 기본적으로 기본 키가 있는 열에는 이미 클러스터된 인덱스가 있습니다.
비클러스터된 인덱스
- 비클러스터형 인덱스는 단순 인덱스와 같습니다.데이터의 신속한 취득을 위해서만 사용됩니다.고유한 데이터를 가지고 있는지 확실하지 않습니다.
클러스터된 인덱스
클러스터된 인덱스는 테이블에서 DATA의 물리적 순서를 결정합니다.따라서 테이블에는 클러스터된 인덱스가1개밖에 없습니다(프라이머리 키/콤포지트 키).
"사전" 다른 인덱스는 필요 없습니다. 단어에 따르면 이미 인덱스가 있습니다.
비클러스터형 인덱스
비클러스터형 색인은 책의 색인과 유사합니다.데이터는 한 곳에 저장됩니다.인덱스는 다른 위치에 저장되고 인덱스는 저장 위치에 대한 포인터를 가집니다.빠른 데이터 검색에 도움이 됩니다.따라서 테이블에는 둘 이상의 비클러스터된 인덱스가 있습니다.
"Biology Book"은 시작할 때 챕터 위치를 가리키는 별도의 인덱스가 있으며 "END"에는 공통 WORDS 위치를 가리키는 다른 인덱스가 있습니다.
매우 단순하고 비기술적인 ROU(Rule of Thumb)는 일반적으로 클러스터된 인덱스가 기본 키(또는 적어도 고유한 열)에 사용되고 비클러스터된 인덱스가 다른 상황(아마도 외부 키)에 사용된다는 것입니다.실제로 SQL Server는 기본 키 열에 클러스터된 인덱스를 만듭니다.이미 학습한 바와 같이 클러스터 인덱스는 디스크에서 데이터를 물리적으로 정렬하는 방식과 관련이 있습니다. 즉, 대부분의 경우 이 인덱스를 선택하는 것이 좋습니다.
클러스터된 인덱스
클러스터된 색인은 기본적으로 트리로 구성된 테이블입니다.클러스터된 인덱스는 실제로는 정렬되지 않은 힙 테이블 공간에 레코드를 저장하는 대신 B+Tree 인덱스로, 클러스터 키 열 값으로 정렬된 리프 노드가 실제 테이블 레코드를 저장합니다(다음 그림 참조).
클러스터 인덱스는 SQL Server 및 MySQL의 기본 테이블 구조입니다.MySQL은 테이블에 기본 키가 없는 경우에도 숨겨진 클러스터 색인을 추가하는 반면, 테이블에 기본 키 열이 있는 경우 SQL Server는 항상 클러스터된 색인을 작성합니다.그렇지 않으면 SQL Server가 힙 테이블로 저장됩니다.
클러스터된 인덱스는 일반적인 CRUD 문과 같이 클러스터된 인덱스 키로 레코드를 필터링하는 쿼리 속도를 높일 수 있습니다.레코드는 리프 노드에 있으므로 기본 키 값으로 레코드를 찾을 때 추가 열 값을 검색할 필요가 없습니다.
예를 들어 SQL 서버에서 다음 SQL 조회를 실행하는 경우:
SELECT PostId, Title
FROM Post
WHERE PostId = ?
시크 하여 "Clustered " 조작을 사용하여 "Cisco Index Seek"를 하는 리프 을 알 수 .Post기록. 클러스터 인덱스 노드를 검색하는 데 필요한 논리 읽기는 다음 두 가지뿐입니다.
|StmtText |
|-------------------------------------------------------------------------------------|
|SELECT PostId, Title FROM Post WHERE PostId = @P0 |
| |--Clustered Index Seek(OBJECT:([high_performance_sql].[dbo].[Post].[PK_Post_Id]), |
| SEEK:([high_performance_sql].[dbo].[Post].[PostID]=[@P0]) ORDERED FORWARD) |
Table 'Post'. Scan count 0, logical reads 2, physical reads 0
비클러스터형 인덱스
클러스터 색인은 일반적으로 기본 키 열 값을 사용하여 작성되므로 다른 열을 사용하는 쿼리 속도를 높이려면 보조 비클러스터 색인을 추가해야 합니다.
세컨더리 인덱스는 다음 그림과 같이 리프 노드에 프라이머리 키 값을 저장합니다.
에하면 세컨더리 인덱스가 됩니다.Title의 Post 삭제:
CREATE INDEX IDX_Post_Title on Post (Title)
그리고 다음 SQL 쿼리를 실행합니다.
SELECT PostId, Title
FROM Post
WHERE Title = ?
은 Index Seek의 을 알 수 .IDX_Post_Title"SQL" "SQL" "SQL" "SQL" "SQL" "SQL" "SQL" "SQL" "SQL" "SQL" "SQL" "SQL" "SQL" :
|StmtText |
|------------------------------------------------------------------------------|
|SELECT PostId, Title FROM Post WHERE Title = @P0 |
| |--Index Seek(OBJECT:([high_performance_sql].[dbo].[Post].[IDX_Post_Title]),|
| SEEK:([high_performance_sql].[dbo].[Post].[Title]=[@P0]) ORDERED FORWARD)|
Table 'Post'. Scan count 1, logical reads 2, physical reads 0
있는 「」로,PostId[ ]은 [Primary Key]에 됩니다.IDX_Post_Title 노드. 이 는 "리프 노드"를 하지 않습니다.Post행을 선택합니다.
클러스터된 인덱스
클러스터된 인덱스는 데이터 행을 키 값을 기준으로 테이블 또는 보기에 정렬하고 저장합니다.인덱스 정의에 포함된 열입니다.데이터 행 자체는 하나의 순서로만 정렬할 수 있으므로 테이블당 클러스터된 인덱스는 하나만 있을 수 있습니다.
테이블의 데이터 행이 정렬된 순서로 저장되는 것은 테이블에 클러스터된 인덱스가 포함되어 있는 경우뿐입니다.테이블에 클러스터된 인덱스가 있는 경우 테이블을 클러스터된 테이블이라고 합니다.테이블에 클러스터된 인덱스가 없는 경우 해당 데이터 행은 힙이라고 하는 순서가 매겨지지 않은 구조에 저장됩니다.
비클러스터화
비클러스터형 인덱스는 데이터 행과 다른 구조를 가집니다.비클러스터형 인덱스에는 비클러스터형 인덱스 키 값이 포함되며 각 키 값 항목에는 키 값을 포함하는 데이터 행에 대한 포인터가 있습니다.비클러스터형 인덱스의 인덱스 행에서 데이터 행으로의 포인터를 행 로케이터라고 합니다.행 로케이터의 구조는 데이터 페이지가 힙 또는 클러스터된 테이블에 저장되는지 여부에 따라 달라집니다.힙의 경우 행 로케이터는 행에 대한 포인터입니다.클러스터된 테이블의 경우 행 로케이터는 클러스터된 인덱스 키입니다.
비클러스터형 인덱스의 리프 수준에 비키 열을 추가하여 기존 인덱스 키 제한을 우회하고 완전히 포괄되고 인덱싱된 쿼리를 실행할 수 있습니다.자세한 내용은 포함된 열을 사용하여 인덱스 만들기를 참조하십시오.인덱스 키 제한에 대한 자세한 내용은 SQL Server의 최대 용량 사양을 참조하십시오.
참고 자료: https://learn.microsoft.com/en-us/sql/relational-databases/indexes/clustered-and-nonclustered-indexes-described
Database Systems에서 15.6.1에서 가져온 "클러스터링 인덱스"에 대한 교과서적 정의를 제시하겠습니다. 완결본:
클러스터링 인덱스에 대해서도 언급할 수 있습니다.클러스터 인덱스는 속성의 인덱스이며, 이 인덱스의 검색 키에 대해 고정된 값을 가진 모든 튜플이 가능한 한 적은 수의 블록에 나타나도록 합니다.
정의를 이해하기 위해 교과서에서 제공하는 예 15.10을 살펴보겠습니다.
★★★
R(a,b)" " " 에 따라 됩니다.a블록으로 포장된 순서대로 저장되는 것은 확실히 클러스터드입니다. on on 。a입니다.는 특정 클러 a a에 .특정 기간 동안aa1, -value a1, "value a1", "value a1"의 값을 가진 모든 :a따라서 있는 , 아마 블록의 될 것입니다.a15. 14 .14 제 a1에 된 바와 값 a1.될 은 낮습니다.가 있기 때문입니다.b은 파일 됩니다.단, "값"은 "값"이 아닌 ,a★★★★★★★★★★★★★★★★★」b매우 밀접하게 관련되어 있습니다.
이 정의에서는 데이터 블록이 디스크 상에서 연속적으로 존재해야 하는 것은 아닙니다.단, 검색 키가 있는 튜플은 가능한 한 적은 수의 데이터 블록으로 압축되어 있을 뿐입니다.
관련 개념은 클러스터 관계입니다.관계는 해당 튜플이 가능한 한 적은 수의 블록으로 채워지면 "클러스터화"됩니다.즉, 디스크 블록의 관점에서는 다른 관계로부터의 튜플이 포함되어 있는 경우, 이러한 관계를 클러스터화할 수 없습니다(즉, 현재 디스크 블록의 관계에 속하지 않는 튜플을 다른 디스크 블록으로부터 스왑 하는 것으로, 이러한 관계를 격납하는 보다 패킹된 방법이 있습니다).확실히.R(a,b)위의 예에서는 클러스터화되어 있습니다.
두 개념을 함께 연결하기 위해 클러스터된 관계는 클러스터링 인덱스와 비클러스터링 인덱스를 가질 수 있습니다.그러나 비클러스터된 관계의 경우 인덱스가 관계의 기본 키 위에 구축되지 않는 한 클러스터링 인덱스를 사용할 수 없습니다.
"클러스터"라는 단어는 데이터베이스 스토리지 측면의 모든 추상화 수준(세 가지 추상화 수준: 튜플, 블록, 파일)에 걸쳐 스팸 처리됩니다."클러스터된 파일"이라는 개념으로, 파일(블록 그룹(1개 이상의 디스크 블록)에 한 관계에서 온 튜플이 포함되는지 아니면 다른 관계에서 온 튜플이 포함되는지 여부를 설명합니다.파일 레벨에서는 클러스터링 인덱스 개념과는 관련이 없습니다.
그러나 일부 교재에서는 클러스터된 파일 정의를 기반으로 클러스터링 인덱스를 정의하는 것을 선호합니다.이러한 두 가지 유형의 정의는 데이터 디스크 블록 또는 파일 측면에서 클러스터된 관계를 정의하든 상관없이 클러스터된 관계 수준에서 동일합니다.이 단락의 링크에서
파일의 A 속성에 대한 인덱스는 다음과 같은 경우 클러스터링 인덱스가 됩니다. 속성 값이 A = a인 모든 튜플은 데이터 파일에 순차적으로(= 연속적으로) 저장됩니다.
튜플을 연속적으로 저장하는 것은 "튜플은 가능한 한 적은 수의 블록으로 압축된다"는 것과 같습니다(파일에 대해 말하는 것과 디스크에 대해 말하는 것의 차이는 미미합니다).이는 태플을 연속적으로 저장하는 것이 "가능한 한 적은 수의 블록으로 압축"하는 방법이기 때문입니다.
클러스터된 인덱스: 테이블에 클러스터된 인덱스가 없는 경우 기본 키 제약 조건은 클러스터된 인덱스를 자동으로 생성합니다.클러스터된 인덱스의 실제 데이터는 인덱스의 리프 레벨에 저장할 수 있습니다.
비클러스터 인덱스 : 비클러스터 인덱스의 실제 데이터는 리프 노드에서 직접 찾을 수 없으며, 실제 데이터를 가리키는 행 로케이터 값만 있기 때문에 추가로 찾아야 합니다.클러스터되지 않은 인덱스는 클러스터된 인덱스로 정렬할 수 없습니다.테이블당 클러스터되지 않은 인덱스가 여러 개 있을 수 있습니다.실제로 사용하는 SQL 서버 버전에 따라 달라집니다.기본적으로 SQL Server 2005는 249개의 비클러스터 인덱스를 지원하며 2008, 2016과 같은 이전 버전의 경우 테이블당 999개의 비클러스터 인덱스를 허용합니다.
클러스터된 인덱스 - 클러스터된 인덱스는 테이블에 데이터가 물리적으로 저장되는 순서를 정의합니다.테이블 데이터는 유일한 방법으로 정렬할 수 있으므로 테이블당 클러스터된 인덱스는 하나만 있을 수 있습니다.SQL Server에서 기본 키 제약 조건은 특정 열에 클러스터된 인덱스를 자동으로 생성합니다.
비클러스터된 인덱스 - 비클러스터된 인덱스는 테이블 내의 실제 데이터를 정렬하지 않습니다.실제로 비클러스터 인덱스는 한 곳에 저장되고 테이블 데이터는 다른 곳에 저장됩니다.책 내용이 한 곳에 있고 색인이 다른 곳에 있는 교과서와 비슷하다.이렇게 하면 테이블당 두 개 이상의 비클러스터 인덱스를 사용할 수 있습니다.여기서 중요한 것은 테이블 내에서 데이터는 클러스터된 인덱스로 정렬된다는 것입니다.그러나 비클러스터된 인덱스 데이터는 지정된 순서로 저장됩니다.인덱스에는 인덱스가 생성되는 열 값과 열 값이 속한 레코드의 주소가 포함됩니다.인덱스가 생성된 열에 대해 쿼리를 실행하면 데이터베이스는 먼저 인덱스로 이동하여 테이블에서 해당 행의 주소를 찾습니다.그런 다음 해당 행 주소로 이동하여 다른 열 값을 가져옵니다.클러스터되지 않은 인덱스가 클러스터된 인덱스보다 느리기 때문에 이 추가 단계로 인해
클러스터된 인덱스와 비클러스터된 인덱스의 차이점
- 테이블당 클러스터된 인덱스는 1개뿐입니다.그러나 단일 테이블에 여러 비클러스터 인덱스를 생성할 수 있습니다.
- 클러스터된 인덱스는 테이블만 정렬합니다.따라서 추가 저장 공간을 사용하지 않습니다.비클러스터된 인덱스는 더 많은 저장 공간을 요구하는 실제 테이블과 다른 위치에 저장됩니다.
- 클러스터된 인덱스는 추가 조회 단계를 포함하지 않으므로 비클러스터된 인덱스보다 빠릅니다.
상세한 것에 대하여는, 이 문서를 참조해 주세요.
언급URL : https://stackoverflow.com/questions/1251636/what-do-clustered-and-non-clustered-index-actually-mean
'programing' 카테고리의 다른 글
| Windows PowerShell: 명령 프롬프트 변경 (0) | 2023.04.08 |
|---|---|
| PSCustom Object에서 해시 테이블로 (0) | 2023.04.08 |
| HTML에 minlength validation 속성이 있습니까? (0) | 2023.04.08 |
| ASP에서 여러 개의 제출 버튼을 처리하는 방법은 무엇입니까?NET MVC 프레임워크? (0) | 2023.04.08 |
| Select 스테이트먼트의 케이스 (0) | 2023.04.08 |