기존 인덱스가 새 인덱스의 모든 열을 포함 할 때이 새 인덱스를 생성하면 성능이 크게 향상되는 이유는 무엇입니까?

Log 및 LogItem 테이블이 있습니다. 둘 다에서 일부 데이터를 가져 오기 위해 쿼리를 작성 중입니다. 수천 개가 Logs있으며 각각 Log최대 125 개를 가질 수 있습니다LogItems

문제의 쿼리가 복잡하므로 건너 뛰고 있습니다 (누군가 생각하면 게시 할 수 있다고 생각하면) SSMS Estimated Query 계획을 실행하면 새로운 비 클러스터 색인이 성능을 최대 100 % 향상시킬 것이라고 말했습니다. .

Existing Index: Non-clustered
Key Colums (LogItem): ParentLogID, DateModified, Name, DatabaseModified

Query Plan Recommendation
CREATE NONCLUSTERED INDEX [LogReportIndex]
ON [dbo].[LogItem] ([ParentLogID],[DatabaseModified])

재미있게, 나는이 새로운 색인을 만들고 쿼리를 실행했으며 놀랍게도 10 초 전에는 쿼리가 실행되기까지 ~ 1 초가 걸렸습니다.

기존 인덱스가이 새 쿼리를 처리한다고 가정했기 때문에 새 쿼리에 사용 된 열에 만 새 인덱스를 생성하면 성능이 향상되는 이유는 무엇입니까? 내 where절에 사용 된 각 고유 한 열 조합에 대한 색인이 있어야합니까 ?

참고 : SQL Server가 내 결과를 캐싱하고 있기 때문에 인덱스를 생성하기 전에 약 25-30 번 쿼리를 실행했으며 인덱스 이후 10-15 초가 걸렸습니다. 이하.

인덱스의 열 순서가 중요합니다. 필터링에 인덱스의 열 1과 4가 필요한 경우 인덱스가 도움이되지 않습니다. 첫 번째 N 개의 연속 열로 필터링 할 때만 유용합니다.

인덱스가 트리이기 때문입니다. 및의 column3 = something다른 값에 속하는 다른 모든 곳에 흩어져 있기 때문에 트리의 모든 노드를 효율적으로 선택할 수 없습니다 . 당신이 안다면 및 뿐만 아니라, 트리의 오른쪽 지점을 찾는 것은 더 생각할 필요 없다.column1column2column1column2

첨단 인덱스가 중요한 것입니다.

쿼리가 인덱스의 최첨단에 의해 "포함"되어 있으면 효율적입니다. 데이터베이스 인덱스는 일반적으로 B-Tree로 구현되며 B-Tree의 구조에 따라 특정 순서로 검색을 수행해야하므로 복합 인덱스의 필드 순서가 중요합니다.

"구멍"이있는 경우 (예 : ParentLogID및 DatabaseModified에서 검색 하지만 인덱스 만있는 경우) 인덱스 {ParentLogID, DateModified, Name, DatabaseModified}의 {ParentLogID}일부만 효율적으로 사용할 수 있습니다.

(참고 : 일부 DBMS는 {DatabaseModified}"스킵 스캔"을 통해이 부분을 활용할 수 있지만, DBMS가 일반 인덱스 액세스보다 훨씬 덜 효율적이라고하더라도) .