MS SQL 데이터베이스에서 자동 색인 도구를 실행했습니다 (색인 통계 테이블을 보는 Microsoft에서 시작한 스크립트- 자동 자동 색인 작성 )을 수정했습니다. 통계에서 생성해야 할 색인에 대한 권장 목록이 생겼습니다.

편집 : 위에서 설명한 색인은 데이터베이스 엔진이 색인을 사용할 수있는 경우 데이터베이스 엔진이 색인에 사용하는 것을 알려주는 정보를 DMV에서 가져 와서 스크립트는 Top x 권장 사항 (검색, 사용자 영향 등)을 취하여 표에 넣습니다.

(스크립트가 무엇을하고 있는지 명확히하기 위해 아래의 Larry Coleman의 답변에서 부분적으로 취한 위의 편집)

데이터베이스 관리자를 처음 사용하고 인터넷을 빠르게 검색 했으므로 급락하여 권장 색인을 맹목적으로 추가하는 것을 꺼려합니다. 그러나 현장에서 경험이없는 경우 권장 사항이 필요한지 여부를 결정하는 방법에 대한 조언을 찾고 있습니다.

SQL 프로파일 러를 실행해야합니까, 아니면 테이블을 쿼리하는 코드를 검사하는 것이 더 낫습니까? 그리고 다른 조언이 있습니까?

내가 사용 제이슨 STRATE의 인덱스 분석 스크립트 (올드 위치) . 기존 색인이 얼마나 많이 사용되었고 누락 된 색인이 얼마나 많이 사용되었는지 알려줍니다. 일반적으로 테이블에서 쿼리의 5 ~ 10 % 이상을 구성하지 않으면 인덱스를 추가하지 않습니다.

그러나 가장 중요한 것은 응용 프로그램이 사용자에게 충분히 빠르게 응답하는지 확인하는 것입니다.

업데이트 : 최신 스크립트에 대한 Jason Strate의 인덱스 분석 블로그 기사 (새 위치)

이중 업데이트 : 요즘에는 인덱스 분석을 수행 할 때 sp_BlitzIndex®를 사용 합니다.

인덱스를 다룰 때 이해해야 할 몇 가지 개념과 용어가 있습니다. 찾기, 스캔 및 조회는 select 문을 통해 색인을 활용하는 방법 중 일부입니다. 키 열의 선택성은 인덱스가 얼마나 효과적인지 결정하는 데 필수적입니다.

요청은 SQL Server 쿼리 최적화 프로그램이 요청한 데이터를 찾는 가장 좋은 방법이 인덱스 내의 범위를 검색하는 것임을 결정할 때 발생합니다. 탐색은 일반적으로 쿼리가 인덱스에 의해 "일괄"될 때 발생합니다. 이는 탐색 술어가 인덱스 키에 있고 표시된 열이 키에 있거나 포함되어 있음을 의미합니다. SQL Server 쿼리 최적화 프로그램에서 데이터를 찾는 가장 좋은 방법은 전체 인덱스를 검색 한 다음 결과를 필터링하는 것으로 결정하면 검색이 수행됩니다. 조회는 일반적으로 인덱스가 요청 된 모든 열을 인덱스 키 또는 포함 된 열에 포함하지 않을 때 발생합니다. 그런 다음 쿼리 최적화 프로그램은 클러스터 된 키 (클러스터 된 인덱스) 또는 RID (힙에 대한)를 사용하여 다른 요청 된 열을 "조회"합니다.

일반적으로 검색 작업은 더 작은 데이터 세트를 물리적으로 쿼리하기 때문에 스캔보다 효율적입니다. 매우 작은 초기 데이터 세트와 같이 그렇지 않은 경우가 있지만 질문의 범위를 넘어서는 상황이 있습니다.

이제 인덱스가 얼마나 효과적인지 결정하는 방법을 물었고 몇 가지 유의해야 할 사항이 있습니다. 클러스터형 인덱스의 키 열을 클러스터링 키라고합니다. 클러스터 된 인덱스의 컨텍스트에서 레코드가 고유하게 만들어지는 방식입니다. 필요한 경우 조회를 수행하기 위해 모든 비 클러스터형 인덱스에는 기본적으로 클러스터 된 키가 포함됩니다. 모든 인덱스는 각 DML 문마다 삽입, 업데이트 또는 삭제됩니다. 말씀 드린 바에 따르면, 명령문의 성능 향상과 삽입, 삭제 및 업데이트의 성능 저하 간의 균형을 맞추는 것이 가장 좋습니다.

인덱스의 효과를 확인하려면 인덱스 키의 선택성을 결정해야합니다. 선택성은 총 레코드에 대한 고유 레코드의 백분율로 정의 할 수 있습니다. 총 레코드가 100 개인 [person] 테이블이 있고 [first_name] 열에 90 개의 고유 한 값이 포함되어 있으면 [first_name] 열이 90 % 선택적이라고 말할 수 있습니다. 선택성이 높을수록 인덱스 키가 더 효율적입니다. 선택성을 염두에두고 가장 선택적인 열을 먼저 색인 키에 두는 것이 가장 좋습니다. 이전 [person] 예를 사용하여 95 % 선택적 [last_name] 열이 있으면 어떻게합니까? [last_name], [first_name]을 인덱스 키로 사용하여 인덱스를 생성하려고합니다.

나는 이것이 조금 오래 걸리는 대답이라는 것을 알고 있지만 실제로 인덱스의 효과를 결정하는 데는 많은 것들이 있으며 성능 향상에 대해 고려해야 할 많은 것들이 있습니다.

나는 최근 BrentOzar Unltd http://www.brentozar.com/blitzindex/ 에서 사람들로부터 환상적인 무료 스크립트를 발견했습니다 .

이것은 어떤 인덱스가 존재하는지, 얼마나 자주 사용되는지, 그리고 쿼리 엔진이 존재하지 않는 인덱스를 얼마나 자주 찾는 지에 대한 좋은 분석을 수행합니다.

일반적으로 지침이 좋습니다. 때때로 그것은 약간의 아이디어를 제안합니다. 나는 일반적으로 지금까지 다음을 수행했습니다.

• 읽지 않은 (또는 한 달에 50 회 미만) 인덱스를 제거했습니다.
• 외래 키와 필드에 가장 명백한 색인을 추가했습니다.

권장 인덱스를 모두 추가하지 않았으며 쿼리 엔진이 다른 새 인덱스 중 일부를 대신 사용하므로 더 이상 권장되지 않는 것을 발견하기 위해 일주일 후로 돌아 왔습니다!

일반적으로 다음에 대한 색인을 피해야합니다.

• 매우 작은 테이블 (50-200 개 미만의 레코드) : 종종 쿼리 엔진이 인덱스로드, 읽기, 처리 등이 아닌 테이블을 스캔하면 속도가 빠릅니다.
• 첫 번째 언급 된 열에서 카디널리티가 낮은 열 ( http://en.wikipedia.org/wiki/Cardinality_(SQL_statements) )에 대한 인덱스는 피하십시오 . 예 : 성별 필드 (M / F)를 인덱싱하는 것은 거의 쓸모가 없으며, 테이블을 스캔하고 해당하는 ~ 50 %를 찾는 것이 실용적입니다. 색인에보다 구체적인 내용 (예 : [생년월일, 성별])이 더 나은 경우, 주어진 기간 동안 모든 남성이 태어날 수 있습니다.

클러스터형 인덱스는 양호합니다. 일반적으로 기본 키를 기반으로합니다. 데이터베이스 엔진이 디스크의 데이터를 올바른 순서로 저장하도록 도와줍니다. 좋은 클러스터형 인덱스로 인해 테이블이 차지하는 공간이 줄어들 기 때문에 가장 큰 테이블의 경우이를 이해하는 것이 매우 중요합니다.

사전에 구조화되지 않은 힙이기 때문에 일부 테이블을 900MB에서 400MB로 줄였습니다. http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx

재구성 / 재 구축

조각난 인덱스를 확인해야합니다. 약간의 조각화는 괜찮습니다. 강박하지 마십시오! http://technet.microsoft.com/en-us/library/ms189858.aspx 재구성과 재구성의 차이점을 알고 있습니다!

정기적으로 검토

쿼리 변경, 데이터 볼륨 변경, 새로운 기능 추가, 기존 기능 제거. 한 달에 한 번 (또는 볼륨이 많은 경우 더 자주)보고 데이터베이스를 도울 수있는 곳을 찾아야합니다!

얼마나

최근 비디오에서 브렌트는 글을 많이 쓰는 테이블 (예 : 주문 테이블)에서 5 개 이상의 색인을 권장하지 않으며, 글을 많이 읽은 경우 (예 : 분석을위한 로깅 테이블) http : / /www.youtube.com/watch?v=gOsflkQkHjg

사무용 겉옷

그것은 달려있다!

마일리지는 데이터베이스에 따라 다릅니다. (현재 / 미래) 더 큰 테이블에서 명백한 (직원 성, 주문 날짜 등)을 가리십시오. 필요에 따라 모니터링, 검토 및 조정하십시오. 데이터베이스를 관리 할 때 일상 점검표의 일부 여야합니다. :)

도움이 되었기를 바랍니다!

일반적으로 특정 워크로드 (쿼리)를 갖고 워크로드에 대한 각 새 인덱스의 영향을 신중하게 테스트합니다. 이 반복 프로세스에는 항상 실행 계획에 대한 신중한 분석이 포함되어야하며, 이는 사용 된 인덱스를 나타냅니다. 쿼리 분석 주제는 긴 주제이며 전용 MSDN 장부터 쿼리 분석을 시작 하는 것이 좋습니다.

때로는 워크로드가 너무 복잡하거나 데이터베이스 설계에 대한 지식이 개략적 인 경우 데이터베이스 엔진 튜닝 관리자 를 사용하여 워크로드를 자동으로 분석하고 인덱스를 제안합니다. 물론 제안은 신중하게 분석하고 그 영향을 즉시 측정해야합니다.

따라서 내 생각에 따라 인덱스를 추가하고 영향을 측정하는 것은 실제로 A / B 테스트 의 경우입니다 . 인덱스없이 작업 부하를 기준선으로 실행 한 다음 인덱스로 실행하고 측정 및 비교합니다. 기준선을 사용하여 관찰하고 측정 된 측정 항목에 따라 영향이 유리한지 결정합니다. 워크로드는 최상의 품질의 테스트 스위트이지만 캡처 된 워크로드를 재생할 수도 있습니다 ( 방법 : 추적 파일 재생 참조) .

더 종합적인 답변은 sys.dm_db_index_usage_stats견해를보고 인덱스가 어떻게 활용되고 있는지 를 보는 것입니다 . 그러나 일반적으로 알 수없는 작업량 (예 : 도움을 요청하는 컨설턴트)이 현장 분석을 수행하는 방법입니다.

SQL 2005부터 SQL Server에는 데이터베이스 엔진이 인덱스에 사용할 수있는 것을 알려주 는 DMV 가 있습니다. 뷰는 어떤 열이 키 열이어야하는지, 어떤 열을 포함해야하는지, 가장 중요한 것은 인덱스가 몇 번 사용되었는지를 알려줍니다.

누락 된 인덱스 쿼리를 탐색 횟수별로 정렬하고 먼저 최상위 인덱스를 추가하는 것이 좋습니다.

^{참조 : 공식 MS DMV 문서}

해당 테이블이 사용되는 방식에 따라 다릅니다. 예를 들어 많은 시간을 읽는 테이블을 가지고 있지만 업데이트 및 삽입은 거의 없습니다. 또한 항상 외래 키 열의 테이블을 쿼리합니다. 읽기 쿼리 속도를 높이기 위해 외래 키에 대해 (클러스터되지 않은) 인덱스를 만드는 것이 좋습니다. 그러나 단점은 삽입, 업데이트가 느려질 것입니다.

쿼리에 걸리는 시간을 알려주는 통계 쿼리는 거의 없습니다. 가장 느린 것부터 시작하십시오. 쿼리 조건 자에 인덱스가없는 경우 인덱스를 만들면 도움이됩니다.