테이블의 인덱스가 사용되지 않는지 확인

불필요한 색인을 찾으려고이 스크립트를 실행했습니다.

select o.name as TableName, i.name as IndexName, p.reserved_page_count * 8.0 / 1024 as     SpaceInMB, s.*
from     sys.dm_db_index_usage_stats s
inner join sys.objects o on s.object_id = o.object_id
inner join sys.indexes i on i.index_id = s.index_id and i.object_id = o.object_id
inner join sys.dm_db_partition_stats p on i.index_id = p.index_id and o.object_id =      p.object_id
where o.name = ‘TableName’

last_user_seek / scan / lookup이 모두 null 인 경우 마지막 재시작 이후에 사용자가 인덱스를 사용한 적이 없다는 것을 알고 있습니다. 그러나 나는 어떤 system_scans / lookups / seeks가… 특정 테이블에서 사용자 활동이없는 5 개를 발견했지만 10 일 전에는 시스템 활동이있는 것을 발견했습니다. 시스템 스캔 / 탐색 / 조회가 무엇인지에 대한 통찰력이있는 사람이 있습니까? 이 테이블은 과도하게 인덱싱 된 것으로 보이며 지방을 다듬고 싶습니다.

인덱스 유지 관리 (재 구축 / 재구성) 및 DBCC CHECKDB 활동 (통계 업데이트) 예정된 유지 보수가 구성되어 있습니까?

사용자 액세스 권한이 없으면이를 비우십시오. 더 이상 사용되지 않는 기간을 염두에 두십시오. 예를 들어 매주 또는 매월보고 작업이 있습니까?

찾고있는 동안 중복 인덱스 도 찾아보십시오.

편집 : SSC 링크 관련

스레드를 통한 빠른 스캔에서 SSC 사람들이 비슷한 생각을 한 것처럼 보입니다. 그러나 그들은이 지수의 "비정기적인"사용에 대해보다 신중한 입장을 취하고 있으며, 누군가가 이유를 들어서 그들에게 완전히 합당한 주장을하게한다는 입장을 취하고 있습니다. 반론은 너무나 자주 반대되는 것입니다. 누군가는 그것이 옳은 일 이라고 생각 했기 때문에 거기 에 뒀지 만 이해력이 부족하거나 테스트가 부족했기 때문에 그렇지 않았습니다.

사용되지 않고 중복 된 인덱스를 삭제하는 것 외에는 아무것도하지 않기 때문에 몇 가지 시스템을 위기에 처하게했습니다. 과도한 인덱싱은 혼돈을 일으킬 수 있습니다.

그것은 당신의 시스템이기 때문에 인덱스를 제자리에 두거나 떨어 뜨릴 위험을 이해하고 평가해야합니다. 삭제를 진행하기로 결정한 경우 수행 한 작업, 수행 이유를 문서화하고 색인을 스크립팅하고 모든 관련 당사자에게 공개하십시오.

Glenn Berry는 누락 된 인덱스를 찾는 데 도움이되는 훌륭한 스크립트를 작성했습니다. 나는 당신의 작업에서 추측 작업의 일부를 가져 오는 그의 스크립트를 사용하는 것이 좋습니다. 이러한 스크립트는 null 또는 0 사용자 조회 / 스캔 / 주를 찾고있을뿐만 아니라 읽기 활동과 쓰기 활동 사이에 큰 차이가있는 인덱스를 찾고 있으며,이를 통해 전체적인 성능이 저하 될 수 있습니다. 나는 그의 대본을 조사 할 것이다-당신 은 그의 글 에서 시작할 수있다 .

나는 시스템 활동에 대해 걱정하지 않을 것입니다. 인덱스를 제거하면 상황이 악화되지는 않습니다. 실제로 해당 인덱스가 존재하기 때문에 해당 인덱스에서만 발생하는 활동 일 수 있습니다. 가장 중요한 것은 사용자 읽기 활동과 사용자 쓰기 활동이며 균형을 유지하는 것입니다.

색인은 또한 사용되지 않더라도 Query Optimizer에 유용한 정보를 제공합니다. 예를 들어, Uniqueity의 영향에 대해 꽤 많은 작업을 수행했습니다. 검색이나 스캔이 없어 고유 인덱스를 제거해도 여전히 성능에 부정적인 영향을 줄 수 있습니다.

다른 사람들이 언급 한 것 외에도 참조 된 FK 열에 대한 인덱스는 탐색 또는 스캔을 표시하지 않지만 커버 아래에서 사용됩니다.