테이블에 인덱스를 추가하면 검색 속도가 빨라지고 삽입 속도가 느리지 만 테이블이 큰 경우에만 많은 리소스를 발견했습니다. 이로 인해 설계 결정 인 절충이 이루어 지지만 인덱스를 사용하기 전에 대략적인 테이블 크기가 있어야합니다. (예를 들어, 10 행은 아마도 그 한계 이하일 것입니다)
아무도이 한계가 어디 있는지 또는 올바른 방향으로 나를 안내 할 수있는 자원을 알고 있습니까?
답변:
정확한 한계는 실제로 미리 결정하기가 어렵습니다.
대부분의 사람들이 과소 평가하는 것은 인덱스가 쿼리에 사용될 후보가되기 전에 인덱스가 충족해야하는 높은 요구 사항입니다.
효율적인 (비 클러스터형) 인덱스
이벤트 훌륭한 선택 전체 행, 예를 들어 반환 매우 작은 비율 (<1 %, <2 %). 선택성이 주어지지 않은 경우-SQL Server의 쿼리 최적화 프로그램은이 인덱스를 무시할 가능성이 높습니다
이상적으로한다 다루 쿼리를, 즉 쿼리에 필요한 모든 TEH 열을 반환. 당신이 1 또는 2 인덱스 열이, 그리고 다른 소수 (2-4) 열을 포함하는 인덱스를 생성 할 수있는 경우 포함 열을 따라서 당신이 할 수 다루 쿼리를 - 다음 기회는 쿼리 최적화 프로그램이 인덱스를 사용하는 것입니다. 또한 코드가 항상 모든 열SELECT * ..... 을 가져 오기 위해 사용 하는 경우 인덱스 사용 가능성이 실제로 크게 줄어 듭니다.
다른 기준도 많이 있다고 확신하지만이 두 가지가 가장 중요한 기준이라고 생각합니다. 물론, 인덱스를 항상 적절하게 유지 관리 (개편, 재구성)하고 인덱스와 관련된 통계가 최신 상태인지 확인해야합니다.
추신 : 외래 키 열의 비 클러스터형 인덱스는 특별한 경우입니다. 기본적으로 항상 JOINFK 제약 조건 뿐만 아니라 참조 무결성 검사 속도를 높이는 데 도움이되므로 항상 추가하는 것이 좋습니다 . 그러나 여기서도 더 유용한 "include"열을 추가하여 FK 열 인덱스를 "확장"하는 것이 절대적으로 유효합니다.
10 개의 행만있는 인덱스에서 개선 된 것을 볼 수 있습니다.
내 컴퓨터의 다음 테스트에서 인덱스가없는 버전은 10.5초 단위로 완료되고 인덱스가 9.8초 단위 인 버전은 3 회 이상 일치합니다.
이 경우 인덱스는 1 개의 리프 페이지로만 구성되지만 슬롯 배열은 인덱스 키 순서로 정렬되므로 존재하므로 SQL Server는 10 개 모두에서 집계를 수행하지 않고 단일 관심 행만 반환 할 수 있습니다.
CREATE TABLE T
(
X INT,
Y CHAR(100) NULL
)
INSERT INTO T (X)
SELECT number
FROM master..spt_values
WHERE type='P' AND number BETWEEN 1 AND 10
set nocount on;
DECLARE @I INT, @X INT
DECLARE @Time DATETIME2(7) = SYSUTCDATETIME()
SET @I = 1
WHILE (@I < 1000000)
BEGIN
SELECT @X = MAX(X)
FROM T
SET @I += 1
END
SELECT DATEDIFF(MICROSECOND, @Time, SYSUTCDATETIME())
CREATE CLUSTERED INDEX IX ON T(X)
SET @Time = SYSUTCDATETIME()
SET @I = 1
WHILE (@I < 1000000)
BEGIN
SELECT @X = MAX(X)
FROM T
SET @I += 1
END
SELECT DATEDIFF(MICROSECOND, @Time, SYSUTCDATETIME())
DROP TABLE T