인덱스를 사용하는 방법을 알고 있습니다. (클러스터 및 비 클러스터) 언제 테이블에서 클러스터되지 않은 인덱스를 사용해야합니까? 내 컬럼을 비 클러스터형 인덱스로 만들려면 어떤 시나리오가 있어야합니다. 나는 msdn 지침을 통과했지만 조금 혼란 스러웠다.인덱스 정의 : 어떤 컬럼 및 성능 영향?
고유 한 열만 NC로 만들거나 다른 열도 NC로 사용해야합니까?
테이블을 NC 인덱스로 오버로드하면 성능이 저하됩니까?
외래 키 인 열에 복합 non-C 인덱스를 사용해야합니까?
기본 키가 클러스터되어야 함을 알고 있습니다. 고유 키는 NC 여야하지만 외부 키는 무엇입니까?
테이블 당 클러스터 된 인덱스 만 가질 수 있습니다. 기본 키일 필요는 없지만 대부분의 경우 기본 키가됩니다.
그 이상 - 정말 & tipping point for what indexes will be used 쿼리에 따라 다릅니다. 그러나 인덱스를 정의하면 DML에 영향을 미친다는 것을 의미합니다. 삽입, 업데이트 & 삭제는 약간의 성능 저하가 발생합니다.
외래 키 인 열에 복합 비 클러스터형 인덱스를 사용해야합니까?
열이 무엇이든 상관없이, 최적화 프로그램이 클러스터 된 인덱스 또는 다른 인덱스를 결정하는 데 중요합니다.
예, 너무 많은 인덱스로 테이블을 오버로드 할 수 있습니다. 일반적으로 인덱스를 추가 할 때마다 인덱스 유지 관리 측면에서 성능이 저하됩니다. 많이 업데이트되는 테이블은 일반적으로 적은 수의 인덱스가 있어야합니다.
또 다른 광범위한 규칙 (RunAs Radio 및 DotNetRocks의 Richard Campbell에서 제공)은 좁은 인덱스보다 더 광범위한 인덱스가 더 잘 수행 될 것입니다. 광범위한 색인은보다 광범위한 조회를 다루며, 조회 Optimizer가 조사 할 수있는 항목이 적습니다. 쿼리 최적화 프로그램의 실행 시간은 제한되어 있음을 기억하십시오.
SQL Server 프로파일 러를 조사하십시오. 거기에 도구가 있습니다 (독립형으로 사용되었지만 변경되었지만 최근에 사용하지 않았습니다). 작업 부하를 분석하고 인덱싱 권장 사항을 작성할 수 있습니다. "직관적으로"선택된 색인보다 더 나은 선택입니다.
인덱스에없는 쿼리를 참조하는 쿼리가있는 경우 SQL 서버 엔진은 테이블 조회를 수행하여 실제 테이블에서 포함되지 않은 열을 가져와야합니다.
이러한 쿼리를 자주 실행하는 경우 인덱스에 참조 된 모든 열을 포함시켜 쿼리를 "덮는"비 클러스터형 인덱스를 만들어야합니다. 여기에는 비 고유 컬럼이 포함되어야합니다.
테이블을 업데이트 할 때마다 인덱스를 업데이트해야하기 때문에 테이블에 인덱스를 추가하면 쓰기 성능이 항상 저하됩니다.
어떤 필드를 조회하고 있습니까? 수색? 기타. 쿼리를 실행할 때 사용하는 필드 (WHERE 절) 을 결정하면 좋은 후보가 될 수 있습니다.
예를 들어 라이브러리를 생각해보십시오. 책 카탈로그에는 ISBN 번호에 대한 클러스터 된 인덱스와 게시 연도 등을 나타내는 비 클러스터형 인덱스가 있습니다.
또한 Bart Duncan이 오래 전에 게시 한 것이 무엇인지 도왔습니다. 그는 이에 대한 공로를 인정받을 자격이 있습니다.
이 기사의 제목은 "SQL 누락 색인 DMV를 사용하고 있습니까?"입니다. 그것을보고이 쿼리를 실행합니다
SELECT
migs.avg_total_user_cost * (migs.avg_user_impact/100.0) * (migs.user_seeks + migs.user_scans) AS improvement_measure,
'CREATE INDEX [missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + CONVERT (varchar, mid.index_handle)
+ '_' + LEFT (PARSENAME(mid.statement, 1), 32) + ']'
+ ' ON ' + mid.statement
+ ' (' + ISNULL (mid.equality_columns,'')
+ CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END
+ ISNULL (mid.inequality_columns, '')
+ ')'
+ ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement,
migs.*, mid.database_id, mid.[object_id]
FROM sys.dm_db_missing_index_groups mig
INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
WHERE migs.avg_total_user_cost * (migs.avg_user_impact/100.0) * (migs.user_seeks + migs.user_scans) > 10
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC
그것은 당신을위한 최고의 솔루션이되지 않습니다하지만 당신이 어떤 인덱스를 결정하는 데 도움이됩니다. 그리고 기사 링크 : http://blogs.msdn.com/bartd/archive/2007/07/19/are-you-using-sql-s-missing-index-dmvs.aspx. 기본적으로 SQL Server에서 PK를 만들 때 기본적으로 클러스터 된 인덱스가 될 필요는 없지만 일반적으로 PK 인 것입니다.
클러스터 된 인덱스은 (예 : 특정 정도까지) 테이블의 물리적 구조를 정의합니다. 그것은 어떤 순서로 데이터가 정렬되는지를 정의합니다. 적어도 대부분의 국가에서 (성, 이름)에 의해 "클러스터"된 전화 번호부를 생각해보십시오.
테이블 당 하나의 클러스터 된 인덱스 만 제공되므로 현명하게 선택하십시오! Queen of Indexing, Kimberly Tripp의 복음에 따르면, 클러스터링 키는 좁고 안정적이어야하며 (변경되지 않음) 고유해야하고 (예!) 이상적으로 증가해야합니다.
클러스터링 키는 각 클러스터되지 않은 색인의 모든 항목에 추가되므로 좁아야합니다. 결국 클러스터링 키는 궁극적으로 실제 데이터를 찾는 데 사용되는 값입니다.
많은 인덱스 값을 지속적으로 업데이트하는 것은 비용이 많이 드는 일입니다. 특히 클러스터링되지 않은 인덱스에서 클러스터링 키를 업데이트해야하므로 안정적이어야합니다.
다시 말해서 실제 데이터를 찾는 데 사용되는 값이기 때문에 고유해야합니다. 고유 한 것으로 보장되지 않는 열을 선택하면 SQL Server는 클러스터링 키에 4 바이트 값을 추가하여 클러스터 키를 "고유하게"만듭니다. 이는 좋지 않습니다.
이상적으로 클러스터링 키는 페이지와 인덱스 조각화가 가장 적어 성능면에서 최상이기 때문에 계속 증가해야합니다.
클러스터링 키의 이상적인 후보는 INT (또는 BIGINT) IDENTITY입니다. 모든 요구 사항을 이상적으로 충족시킵니다.
클러스터되지 않은 색인은 - 현명하게 사용하고 선택하십시오! 내가 줄 수있는 일반적인 규칙은 하나뿐입니다. 다른 테이블을 참조하는 외래 키의 일부인 모든 열은 인덱스에 있어야합니다. (SQL Server는 널리 알려진 신념과 많은 신화와는 달리) 그러한 인덱스를 제자리에 두지 않습니다 자동적으로 - 절대로 없었습니다.
다른 것 - 시스템을 감시하고 어떤 종류의 쿼리가 있는지 확인해야합니다. WHERE 또는 SORT 절에 나타나는 모든 열은 잠재적 인 후보가 될 수 있지만 인덱스가 너무 많으면 좋지 않습니다. 어느 쪽이든 ....당신이 또는 클러스터 된 인덱스를해서는 안 경우
소원 나는 한 번 이상이 투표에 투표 할 수있었습니다. 좋은 대답! –
@CylonCat : 정말 고마워요! 기꺼이 누군가 –
+1에게 매우 유용합니다. 받아 들여지지 않았습니다. OMG Ponies는 Clustered 인덱스가 아닌 것에 대해 더 많이 알기 위해 매우 좋은 링크를 제공했습니다. –
(보통 테이블 타격 양과 종류의 SELECT 문에 의해 지배)를 워크로드
행의 디스크 저장 순서를 강제로 클러스터 된 인덱스가 따라 할에 따라 달라집니다 클러스터 된 인덱스 값에 적용합니다. (이 이유 때문에 테이블 당 클러스터 인덱스는 단 한 번만 디스크에 저장되기 때문에 테이블 당 하나의 클러스터 된 인덱스 만있을 수 있습니다.) 대부분의 쿼리가 항상 관련 행 그룹을 요구하는 경우 의미가 있습니다.
예 : CustomerOrders를 저장하고 있고 특정 기간 동안 고객과 관계없이 CustomerOrders 수를 알고 싶다고 가정 해보십시오. 이 경우 첫 x 째 C 럼으로 OrderDate를 사용하여 clusterd 색인을 작성하는 것이 유용 할 수 있습니다. 반면에 동일한 CustomerId를 가진 모든 CustomerOrders를 자주 찾는 경우에는 CustomerId를 클러스터 된 인덱스의 첫 번째 열로 지정하는 것이 좋습니다.
클러스터 된 인덱스의 단점은 클러스터 된 인덱스 자체가 아니라 보조 인덱스입니다. 보조 인덱스는 클러스터되지 않습니다 (정의에 따라 행은 한 번만 저장 될 수 있고 클러스터 된 인덱스)이고 인덱스 항목은 클러스터 된 인덱스의 인덱스 항목을 가리 킵니다. 따라서 보조 인덱스를 통해 행을 검색하려면 보조 읽기 중 하나와 보조 인덱스 중 하나를 가리키는 클러스터 된 인덱스 중 하나를 선택해야합니다.
비 클러스터형 인덱스에서만 intrested입니다. NCI를 많은 사람들에게 알릴 수 있기를 바란다. –
질문 2 개를 추가했습니다. –