여러 테이블에서 조인을 수행하는 쿼리가 있습니다. 테이블의 외래 키에 클러스터되지 않은 인덱스가 있고 기본 키에 클러스터 된 인덱스가 있습니다. 쿼리 계획을 분석 할 때 쿼리 최적화 프로그램이 모든 테이블에서 클러스터 된 인덱스 검색을 선택했거나 어떤 경우 비 클러스터 인덱스 스캔과 키 조회를 조합하여 다른 비 키 열을 가져 오는 것으로 생각했습니다. 이 문제를 해결하기 위해 클러스터되지 않은 인덱스에서이 쿼리에 필요한 키가 아닌 열을 포함 (포함)했습니다. 이 결과로 클러스터되지 않은 인덱스 검색/검색이 예상대로 수행되는 것을 볼 수있었습니다.커버링 인덱스의 유용성
이제 다른 많은 키가 아닌 열이 결과 집합의 일부가되어야하는 경우, 클러스터되지 않은 인덱스에 모든 열을 추가하여 (INCLUDING) 결국 개선 될 수 있습니다. 모든 쿼리의 성능 이것이 좋은 생각일까요?
감사합니다.
사용법을 잘 이해하고있는 사례입니다. 쿼리 할 수있는 모든 것에 대해 인덱스를 추가하는 것은 정말 쉽지만 모든 것과 마찬가지로 트레이드 오프입니다. 모든 색인은 시간과 저장소 비용이 들기 때문에 삽입/업데이트 속도가 느려지고 색인 비용이 높을수록 색인이 많이 생성됩니다.
사용량이 기록을 읽는 것이 좋으면 모든 것이 잘되고 저장 비용을 지불하기 만하면됩니다. 쓰기에 대해 적절한 성능이 필요한 경우 실제로 할 수있는 것은 응용 프로그램을 이해하고 가장 중요한 항목을 색인하는 것입니다.
"내부 SQL 서버"시리즈의 도서 (Kalen Delaney 외)를 강력하게 추천합니다. 많은 도움이 되겠지만, 당신이 만드는 트레이드 오프를 이해하는 데 도움이 될 것입니다.
WHERE 절에 필요한 열이 포함 된 것처럼 들리므로 결과적으로 인덱스 검색이 발생합니다.
SELECT 목록에있는 열을 포함 할 수도 있습니다. 그러면 다른 이점이 있습니다. 인덱스에 SELECT 목록을 포함하여 쿼리에 필요한 모든 필드가 포함되어 있으면 쿼리 결과를 인덱스에서 곧바로 반환 할 수 있으며 전혀 테이블 레코드로 돌아갈 필요가 없습니다.
물론 UPDATE, INSERT 및 DELETE 작업에는 추가 인덱스 구축 비용이 포함됩니다.
SQL Server Management Studio 도구> SQL Server 프로파일 러를 실행하여 현재 데이터베이스 작업 샘플을 얻을 수 있습니다. 이를 Tools> Database Engine Tuning Advisor에 제공 할 수 있습니다. 많은 INSERT 및 UPDATE 활동이있는 경우, Tuning Advisor는 일부 색인 제거를 제안 할 수 있습니다. 활동이 주로 SELECT 문인 경우 추가 색인을 제안 할 가능성이 있습니다.
데이터베이스 엔진 튜닝 관리자는 설명하는 것처럼 많은 열에 대해 인덱스를 다루는 것이 좋습니다. 이 문제에 대한 제안과 함께 가끔씩 특정 쿼리에 특정 성능 문제가없는 한 인덱싱을 키 열과 조건 열로 제한하는 경우가 있습니다.