질문자 :P.K
나는 DB에 대한 노출이 제한적이며 DB를 응용 프로그램 프로그래머로만 사용했습니다. 나는에 대해 알고 싶은 Clustered 와 Non clustered indexes . 나는 구글링했고 내가 찾은 것은 :
클러스터형 인덱스는 테이블의 레코드가 물리적으로 저장되는 방식을 재정렬하는 특수한 유형의 인덱스입니다. 따라서 테이블에는 클러스터형 인덱스가 하나만 있을 수 있습니다. 클러스터형 인덱스의 리프 노드에는 데이터 페이지가 포함됩니다. 비클러스터형 인덱스는 인덱스의 논리적 순서가 디스크에 있는 행의 물리적으로 저장된 순서와 일치하지 않는 특수한 유형의 인덱스입니다. 비클러스터형 인덱스의 리프 노드는 데이터 페이지로 구성되지 않습니다. 대신 리프 노드에는 인덱스 행이 포함됩니다.
SO에서 찾은 것은 클러스터형 인덱스와 비클러스터형 인덱스의 차이점은 무엇입니까? .
누군가 이것을 평범한 영어로 설명할 수 있습니까?
클러스터형 인덱스를 사용하면 행이 인덱스와 동일한 순서로 디스크에 물리적으로 저장됩니다. 따라서 클러스터형 인덱스는 하나만 있을 수 있습니다.
클러스터되지 않은 인덱스에는 실제 행에 대한 포인터가 있는 두 번째 목록이 있습니다. 클러스터되지 않은 인덱스를 많이 가질 수 있지만 각각의 새 인덱스는 새 레코드를 작성하는 데 걸리는 시간을 증가시킵니다.
모든 열을 다시 가져오려면 일반적으로 클러스터형 인덱스에서 읽는 것이 더 빠릅니다. 먼저 인덱스로 이동한 다음 테이블로 이동할 필요가 없습니다.
데이터를 재정렬해야 하는 경우 클러스터형 인덱스가 있는 테이블에 쓰는 작업이 느려질 수 있습니다.
클러스터형 인덱스는 디스크에서 실제로 서로 가까운 가까운 값을 저장하도록 데이터베이스에 지시한다는 의미입니다. 이것은 클러스터된 인덱스 값의 일부 범위에 속하는 레코드의 빠른 스캔/검색의 이점이 있습니다.
예를 들어 Customer 및 Order라는 두 개의 테이블이 있습니다.
Customer ---------- ID Name Address Order ---------- ID CustomerID Price특정 고객의 모든 주문을 빠르게 검색하려면 주문 테이블의 "CustomerID" 열에 클러스터형 인덱스를 생성할 수 있습니다. 이렇게 하면 동일한 CustomerID를 가진 레코드가 물리적으로 디스크(클러스터형)에 서로 가깝게 저장되어 검색 속도가 빨라집니다.
추신: CustomerID의 인덱스는 분명히 고유하지 않으므로 인덱스를 "고유화"하기 위해 두 번째 필드를 추가하거나 데이터베이스가 이를 처리하도록 해야 하지만 그건 또 다른 이야기입니다.
다중 색인에 관하여. 클러스터형 인덱스는 데이터가 물리적으로 정렬되는 방식을 정의하기 때문에 테이블당 하나의 클러스터형 인덱스만 가질 수 있습니다. 비유를 원한다면 많은 테이블이 있는 큰 방을 상상해 보십시오. 이 테이블을 여러 줄로 만들거나 모두 함께 당겨서 큰 회의 테이블을 만들 수 있지만 동시에 양방향으로 사용할 수는 없습니다. 테이블에는 다른 인덱스가 있을 수 있으며 클러스터형 인덱스의 항목을 가리키며 차례로 실제 데이터를 찾을 위치를 알려줍니다.
SQL Server에서 클러스터형 인덱스와 비클러스터형 인덱스 모두 행 지향 저장소는 B 트리로 구성됩니다.
( 이미지 출처 )
클러스터 인덱스와 비 클러스터 인덱스의 주요 차이점은 클러스터 된 인덱스의 잎 수준은 테이블 것입니다. 여기에는 두 가지 의미가 있습니다.
INCLUDE 절(SQL Server 2005 이후)을 사용하여 키가 아닌 모든 열을 명시적으로 포함함으로써 포인트 1을 수행할 수도 있지만 이는 보조 표현이며 항상 주변에 다른 데이터 복사본(테이블 자체)이 있습니다.
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)이며 세 가지 구성 요소(File:Page: Slot)로 구성됩니다. 클러스터형 인덱스의 경우 행 로케이터는 논리적입니다(클러스터형 인덱스 키).
후자의 경우 클러스터되지 않은 인덱스가 이미 자연스럽게 CI 키 열을 NCI 키 열 또는 INCLUDE -d 열로 포함하면 아무 것도 추가되지 않습니다. 그렇지 않으면 누락된 CI 키 열이 NCI에 자동으로 추가됩니다.
SQL Server는 항상 키 열이 두 유형의 인덱스에 대해 고유한지 확인합니다. 그러나 고유한 것으로 선언되지 않은 인덱스에 대해 이것이 적용되는 메커니즘은 두 인덱스 유형 간에 다릅니다.
클러스터형 인덱스는 기존 행을 복제하는 키 값이 있는 모든 행에 대해 uniquifier 이것은 단지 오름차순 정수입니다.
고유 SQL Server로 선언되지 않은 비클러스터형 인덱스의 경우 행 로케이터를 비클러스터형 인덱스 키에 자동으로 추가합니다. 이것은 실제로 중복된 행뿐만 아니라 모든 행에 적용됩니다.
클러스터형 및 비클러스터형 명명법은 열 저장소 인덱스에도 사용됩니다. SQL Server Column Stores 상태에 대한 문서 개선 사항
열 저장소 데이터는 어떤 키에서도 실제로 "클러스터형"이 아니지만 기본 인덱스를 클러스터형 인덱스로 참조하는 기존 SQL Server 규칙을 유지하기로 결정했습니다.
나는 이것이 매우 오래된 질문이라는 것을 알고 있지만 위의 훌륭한 답변을 설명하는 데 도움이 되는 비유를 제공할 것이라고 생각했습니다.
공공 도서관에 들어가면 책이 모두 특정 순서로 배열되어 있음을 알 수 있습니다(대부분 듀이 십진법 또는 DDS). 이것은 책의 "클러스터형 인덱스" 에 해당합니다. 원하는 책의 DDS#이 005.7565 F736s 001-099 또는 이와 유사한 레이블이 지정된 책장 행을 찾는 것으로 시작합니다. (스택 끝에 있는 이 끝 표시는 색인의 "중간 노드"에 해당합니다.) 결국 005.7450 - 005.7600 레이블이 지정된 특정 선반으로 드릴다운한 다음 지정된 DDS#가 있는 책을 찾을 때까지 스캔합니다. , 그리고 그 시점에서 당신은 당신의 책을 발견했습니다.
그러나 책의 DDS#을 기억하고 도서관에 오지 않았다면 도움을 줄 두 번째 색인이 필요할 것입니다. 옛날에는 도서관 앞에 "카드 카탈로그"라고 하는 멋진 서랍장이 있었습니다. 그 안에는 수천 개의 3x5 카드가 있었습니다. 각 책마다 하나씩 알파벳 순서(아마도 제목순)로 정렬되어 있었습니다. 이것은 "비클러스터형 인덱스"에 해당 합니다. 이러한 카드 카탈로그는 계층 구조로 구성되어 각 서랍에 포함된 카드 범위( Ka - Kl , 즉 "중간 노드")로 레이블이 지정됩니다. 다시 한 번, 당신은 당신의 책을 찾을 때까지 파고들겠지만, 이 경우에 당신이 그것을 발견하면(즉, "리프 노드"), 당신은 책 자체를 가지고 있지 않고 인덱스 번호가 있는 카드만 가지고 있습니다. (DDS#) 클러스터형 인덱스에서 실제 책을 찾을 수 있습니다.
물론 사서가 모든 카드를 복사하고 별도의 카드 카탈로그에서 다른 순서로 정렬하는 것을 막을 수 있는 것은 없습니다. (일반적으로 이러한 카탈로그가 두 개 이상 있었습니다. 하나는 저자 이름별로 정렬되고 다른 하나는 제목별로 정렬됩니다.) 원칙적으로 이러한 "비클러스터형" 인덱스를 원하는 만큼 가질 수 있습니다.
클러스터형 인덱스와 비클러스터형 인덱스의 몇 가지 특징은 다음과 같습니다.
create Index index_name(col1, col2, col.....) .매우 간단하고 비기술적인 경험에 따르면 클러스터형 인덱스는 일반적으로 기본 키(또는 최소한 고유 열)에 사용되고 비클러스터형 인덱스는 다른 상황(외래 키)에 사용됩니다. . 실제로 SQL Server는 기본적으로 기본 키 열에 클러스터형 인덱스를 만듭니다. 배우게 되겠지만 클러스터형 인덱스는 데이터가 디스크에서 물리적으로 정렬되는 방식과 관련이 있습니다. 즉, 대부분의 상황에서 좋은 선택입니다.
클러스터형 인덱스
클러스터형 인덱스는 테이블에서 DATA의 물리적 순서를 결정합니다. 이러한 이유로 테이블에는 클러스터형 인덱스가 1개만 있습니다.
" 사전 " 다른 인덱스 필요 없음, 단어에 따라 이미 인덱스
비클러스터형 인덱스
클러스터되지 않은 인덱스는 책의 인덱스와 유사합니다. 데이터는 한 곳에 저장됩니다. 인덱스가 다른 위치에 저장되고 인덱스에 데이터의 저장 위치에 대한 포인터가 있습니다. 이러한 이유로 테이블에는 1개 이상의 비클러스터형 인덱스가 있습니다.
클러스터형 인덱스는 기본적으로 트리로 구성된 테이블입니다. 클러스터형 인덱스는 정렬되지 않은 힙 테이블스페이스에 레코드를 저장하는 대신 실제로 클러스터 키 열 값으로 정렬된 리프 노드가 있는 B+트리 인덱스이며 다음 다이어그램과 같이 실제 테이블 레코드를 저장합니다.
클러스터형 인덱스는 SQL Server 및 MySQL의 기본 테이블 구조입니다. MySQL은 테이블에 기본 키가 없는 경우에도 숨겨진 클러스터 인덱스를 추가하지만 테이블에 기본 키 열이 있는 경우 SQL Server는 항상 클러스터형 인덱스를 빌드합니다. 그렇지 않으면 SQL Server가 힙 테이블로 저장됩니다.
클러스터형 인덱스는 일반적인 CRUD 문과 같이 클러스터형 인덱스 키로 레코드를 필터링하는 쿼리의 속도를 높일 수 있습니다. 레코드는 리프 노드에 있으므로 기본 키 값으로 레코드를 찾을 때 추가 열 값에 대한 추가 조회가 없습니다.
예를 들어 SQL Server에서 다음 SQL 쿼리를 실행할 때:
SELECT PostId, Title FROM Post WHERE PostId = ? 실행 계획이 클러스터형 인덱스 검색 작업을 사용하여 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클러스터형 인덱스는 일반적으로 기본 키 열 값을 사용하여 작성되므로 다른 열을 사용하는 쿼리의 속도를 높이려면 보조 비클러스터형 인덱스를 추가해야 합니다.
Secondary Index는 다음 다이어그램과 같이 리프 노드에 기본 키 값을 저장합니다.
Post 테이블 Title 열에 Secondary Index를 생성하면:
CREATE INDEX IDX_Post_Title on Post (Title)그리고 다음 SQL 쿼리를 실행합니다.
SELECT PostId, Title FROM Post WHERE Title = ? IDX_Post_Title 인덱스에서 관심 있는 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 기본 키 열 값이 IDX_Post_Title 리프 노드에 저장되므로 이 쿼리는 클러스터형 인덱스에서 Post 행을 찾기 위해 추가 조회가 필요하지 않습니다.
클러스터형 인덱스
클러스터형 인덱스는 키 값을 기반으로 테이블 또는 뷰의 데이터 행을 정렬하고 저장합니다. 인덱스 정의에 포함된 열입니다. 데이터 행 자체는 한 가지 순서로만 정렬할 수 있으므로 테이블당 클러스터형 인덱스는 하나만 있을 수 있습니다.
테이블의 데이터 행이 정렬된 순서로 저장되는 경우는 테이블에 클러스터형 인덱스가 포함된 경우뿐입니다. 테이블에 클러스터형 인덱스가 있는 경우 테이블을 클러스터형 테이블이라고 합니다. 테이블에 클러스터형 인덱스가 없는 경우 해당 데이터 행은 힙이라고 하는 정렬되지 않은 구조에 저장됩니다.
클러스터되지 않은
비클러스터형 인덱스에는 데이터 행과 별도의 구조가 있습니다. 비클러스터형 인덱스에는 비클러스터형 인덱스 키 값이 포함되고 각 키 값 항목에는 키 값이 포함된 데이터 행에 대한 포인터가 있습니다. 비클러스터형 인덱스의 인덱스 행에서 데이터 행으로의 포인터를 행 로케이터라고 합니다. 행 로케이터의 구조는 데이터 페이지가 힙에 저장되는지 클러스터링된 테이블에 저장되는지에 따라 다릅니다. 힙의 경우 행 로케이터는 행에 대한 포인터입니다. 클러스터형 테이블의 경우 행 로케이터는 클러스터형 인덱스 키입니다.
비클러스터형 인덱스의 리프 수준에 키가 아닌 열을 추가하여 기존 인덱스 키 제한을 우회하고 완전히 포함된 인덱싱된 쿼리를 실행할 수 있습니다. 자세한 내용은 포함된 열이 있는 인덱스 생성을 참조하십시오. 인덱스 키 제한에 대한 자세한 내용은 SQL Server의 최대 용량 사양을 참조하세요.
Database Systems: The Complete Book의 15.6.1에서 가져온 "클러스터링 인덱스"에 대한 교과서 정의를 제공하겠습니다.
또한 클러스터링 인덱스 는 이 인덱스의 검색 키에 대해 고정된 값을 가진 모든 튜플이 보유할 수 있는 최소한의 블록에 나타나도록 하는 속성 또는 속성에 대한 인덱스입니다.
정의를 이해하기 위해 교과서에서 제공하는 예제 15.10을 살펴보겠습니다.
릴레이션
R(a,b)속성에 정렬 블록으로 충전하고 그 순서에 저장된, 반드시 clusterd이다.a에 인덱스aA가 주어진에 대한 이후, 클러스터링 인덱스입니다 - 값 A1을 위해 그 값을 가진 모든 튜플aa연속이다. 따라서 그림 15.14에서 제안한 것처럼 -값 a1a첫 번째 및 마지막 블록을 제외하고 블록으로 묶인 것처럼 보입니다.ba및b값이 매우 밀접하게 상관되지 않는 한 파일 전체에 분산되기 때문에 b에 대한 인덱스는 클러스터링될 가능성이 없습니다.
정의는 데이터 블록이 디스크에서 연속적이어야 한다고 강제하지는 않습니다. 검색 키가 있는 튜플은 가능한 한 적은 수의 데이터 블록으로 압축된다고만 말합니다.
관련 개념은 클러스터링된 관계 입니다. 관계의 튜플이 해당 튜플을 보유할 수 있는 대략적인 블록 수만큼 압축되면 관계는 "클러스터형"입니다. 즉, 디스크 블록 관점에서 다른 관계의 튜플이 포함되어 있으면 해당 관계를 클러스터링할 수 없습니다(즉, 다른 디스크 블록에서 해당 관계의 튜플을 튜플은 현재 디스크 블록의 관계에 속하지 않습니다. 분명히 R(a,b) 는 클러스터링되어 있습니다.
두 개념을 함께 연결하기 위해 클러스터된 관계는 클러스터링 인덱스와 비클러스터링 인덱스를 가질 수 있습니다. 그러나 클러스터링되지 않은 관계의 경우 인덱스가 관계의 기본 키 위에 구축되지 않으면 클러스터링 인덱스가 불가능합니다.
"클러스터"라는 단어는 데이터베이스 스토리지 측의 모든 추상화 수준(3가지 추상화 수준: 튜플, 블록, 파일)에 걸쳐 스팸됩니다. 파일(블록 그룹(하나 이상의 디스크 블록)에 대한 추상화)이 하나의 관계 또는 다른 관계의 튜플을 포함하는지 여부를 설명하는 " 클러스터된 파일 "이라는 개념입니다. 파일 수준에 있으므로 클러스터링 인덱스 개념과 관련이 없습니다.
그러나 일부 교재 에서는 클러스터링된 파일 정의를 기반으로 클러스터링 인덱스를 정의하는 것을 선호합니다. 이 두 가지 유형의 정의는 클러스터 관계를 데이터 디스크 블록 또는 파일 측면에서 정의하는지 여부에 관계없이 클러스터 관계 수준에서 동일합니다. 이 단락의 링크에서
파일의 속성 A에 대한 인덱스는 다음과 같은 경우 클러스터링 인덱스입니다. 속성 값 A = a를 가진 모든 튜플이 데이터 파일에 순차적으로(= 연속적으로) 저장됩니다.
튜플을 연속적으로 저장하는 것은 "튜플이 해당 튜플을 담을 수 있는 만큼의 블록으로 압축됩니다"라고 말하는 것과 같습니다(하나는 파일에 대해 이야기하고 다른 하나는 디스크에 대해 이야기하는 데 약간의 차이가 있음). 튜플을 연속적으로 저장하는 것이 "거의 해당 튜플을 보유할 수 있는 블록 수만큼 압축"을 달성하는 방법이기 때문입니다.
클러스터형 인덱스: 기본 키 제약 조건은 클러스터형 인덱스가 테이블에 이미 존재하지 않는 경우 자동으로 클러스터형 인덱스를 생성합니다. 클러스터형 인덱스의 실제 데이터는 인덱스의 리프 수준에 저장할 수 있습니다.
비클러스터형 인덱스: 비클러스터형 인덱스의 실제 데이터는 리프 노드에서 직접 찾을 수 없으며 대신 실제 데이터를 가리키는 행 로케이터 값만 있기 때문에 찾기 위해 추가 단계가 필요합니다. 클러스터되지 않은 인덱스는 클러스터형 인덱스로 정렬할 수 없습니다. 테이블당 클러스터되지 않은 인덱스가 여러 개 있을 수 있으며 실제로 사용 중인 SQL Server 버전에 따라 다릅니다. 기본적으로 SQL Server 2005는 249개의 클러스터되지 않은 인덱스를 허용하고 2008, 2016과 같은 상위 버전의 경우 테이블당 999개의 클러스터되지 않은 인덱스를 허용합니다.
클러스터형 인덱스 - 클러스터형 인덱스는 데이터가 테이블에 물리적으로 저장되는 순서를 정의합니다. 테이블 데이터는 한 가지 방법으로만 정렬할 수 있으므로 테이블당 클러스터형 인덱스는 하나만 있을 수 있습니다. SQL Server에서 기본 키 제약 조건은 해당 특정 열에 클러스터형 인덱스를 자동으로 만듭니다.
비클러스터형 인덱스 - 비클러스터형 인덱스는 테이블 내부의 물리적 데이터를 정렬하지 않습니다. 실제로 클러스터되지 않은 인덱스는 한 곳에 저장되고 테이블 데이터는 다른 곳에 저장됩니다. 이것은 책의 내용이 한 곳에 있고 색인이 다른 곳에 있는 교과서와 유사합니다. 이렇게 하면 테이블당 둘 이상의 비클러스터형 인덱스가 허용됩니다. 여기서 테이블 내부의 데이터는 클러스터형 인덱스에 따라 정렬된다는 점을 언급하는 것이 중요합니다. 그러나 클러스터되지 않은 인덱스 내부에는 데이터가 지정된 순서로 저장됩니다. 인덱스는 인덱스가 생성된 열 값과 해당 열 값이 속한 레코드의 주소를 포함합니다. 인덱스가 생성된 열에 대해 쿼리가 실행되면 데이터베이스는 먼저 인덱스로 이동하여 인덱스를 찾습니다. 테이블에서 해당 행의 주소입니다. 그런 다음 해당 행 주소로 이동하여 다른 열 값을 가져옵니다. 클러스터되지 않은 인덱스가 클러스터된 인덱스보다 느린 것은 이 추가 단계 때문입니다.
클러스터형 인덱스와 비클러스터형 인덱스의 차이점
자세한 내용은 이 문서를 참조하십시오.
출처 : http:www.stackoverflow.com/questions/1251636/what-do-clustered-and-non-clustered-index-actually-mean