인덱스를 필터링 된 (널이 아닌 값) 인덱스로 바꾸는 효과는 무엇입니까?

우리 프로젝트는 매우 크고 매우 복잡한 데이터베이스를 운영합니다. 약 한 달 전에 null 값을 포함하는 인덱싱 된 열이 사용하는 공간이 너무 커지고 있음을 알았습니다. 이에 대한 응답으로 1 % 이상의 null 값을 포함하는 모든 단일 열 인덱스를 동적으로 검색하는 스크립트로 작성한 다음 값이 NULL이 아닌 조건에서 해당 인덱스를 필터링 된 인덱스로 삭제하고 다시 만듭니다. 이는 데이터베이스 전체에 수백 개의 인덱스를 삭제하고 다시 생성하며 일반적으로 전체 DB가 사용하는 공간의 거의 15 %를 확보합니다.

이제 이것에 대해 두 가지 질문이 있습니다.

A) 이런 방식으로 필터링 된 인덱스를 사용하면 어떤 단점이 있습니까? 성능 만 향상시킬 것이라고 생각하지만 성능 위험이 있습니까?

B) 우리는 나중에 검사 할 때 모든 것이 예상대로 정확하게 진행되었지만 인덱스를 삭제하고 다시 만드는 데 오류 ( 'XYZ가 존재하지 않거나 권한이 없기 때문에 인덱스 XYZ를 삭제할 수 없습니다' )를 받았습니다 . 어떻게 이런 일이 일어날 수 있습니까?

도움을 주셔서 감사합니다!

편집 : @Thomas Kejser 님의 질문에 답변

안녕하세요, 감사합니다. 그러나 이것은 재앙이었습니다. 당시 우리는 다음과 같은 몇 가지 사항을 이해하지 못했습니다.

1. 쿼리 중에 SQLOS는 테이블 열 조인에 NULL 값을 사용할 수없는 것으로 결정하기 전에 인덱스 계획을 만듭니다. IE에서는 쿼리에 사용 된 모든 필터링 된 인덱스에 대해 인덱스에 맞는 WHERE 절 필터가 있어야합니다. 그렇지 않으면 인덱스가 전혀 사용되지 않습니다.
2. 인덱스를 삭제 및 작성하고 통계를 중복 업데이트 한 후에도 업데이트 된 계획을 작성하기에 충분하지 않을 수 있습니다. 일부 경우에는 작업량이 충분하기 때문에 SQL Server에서 계획을 다시 평가해야합니다.
3. 상식과 논리만으로는 판단하기 어려운 실행 플래너의 기능에는 몇 가지 이색적인 것이 있습니다. 다른 쿼리의 수천 가지 코드 숨김 생성 변형으로도 쓸모없는 인덱스는 중요한 쿼리에 사용되는 일부 통계 및 쿼리 계획에 도움이 될 수 있습니다.

결국 이러한 변경 사항이 되돌려졌습니다. 따라서 필터링 된 인덱스는 강력한 도구이지만 해당 열에서 어떤 데이터를 가져 오는지 정확하게 이해해야합니다. 공간 문제를 제외하고 일반 인덱스를 적용하기가 쉽지 않은 경우 필터링 된 인덱스는 매우 맞춤화 된 솔루션을 나타냅니다. 그것들은 확실히 일반 인덱스를 대체하는 것이 아니라 필요한 특별한 상황에서 확장됩니다.

매우 흥미로운 접근법. 창의성에 대한 나의 공감.

공간을 회수했기 때문에 원래 색인이 더 이상 존재하지 않는다고 가정합니까? 필터링 된 인덱스의 단점은 다음과 같습니다.

• 너무 많으면 옵티마이 저의 검색 공간이 너무 커져 옵티마이 저가 시간 종료됨에 따라 쿼리 계획이 나빠질 수 있습니다.
• 필터링되지 않은 동등한 항목이 있어도 필터링 된 인덱스가 고려되지 않는 상황이 몇 가지 있습니다. 특히 인덱싱 된 열에서 해시 조인을 얻거나 열없이 필터를 사용하여 열을 ORDER하려고하면이 문제가 발생할 수 있습니다.
• 쿼리 매개 변수화는 필터링 된 인덱스에서 작동하지 않습니다 ( http://www.sqlservercentral.com/blogs/practicalsqldba/2013/04/08/sql-server-part-9-filtered-index-a-new-way- 참조) 성능 향상을 위해 / )

실제로는 필터링 된 인덱스가 끔찍한 쿼리 계획을 초래할 수 있으므로 필터링 된 인덱스에 매우주의해야한다는 것을 의미합니다. 나는 그것들을 쓸모가 없다고 부르지 않을 것이지만, 그것들을 대체물이 아닌 전통적인 색인에 대한 추가 물로 본다.

Thomas Kejser는이 주제에 대해 잘 대답했습니다 .

나는 단지 2 센트를 추가하는 것에 대해 생각했습니다.

필터링 된 인덱스의 where와 쿼리의 where 절을 정확히 일치시킬 때 필터링 된 인덱스 만 사용되는 것을 보았습니다 (실행 계획에 표시됨).

인덱싱 된 뷰 를 사용해 보셨습니까 ? 스파 스 열 ?

내부 조인트 만있는 한 필터링 된 인덱스의 where 절을 포함하는 인덱싱 된 뷰를 만들 수 있으며 대신 뷰를 사용할 수 있다고 생각합니다.

하나 이상의 뷰가있을 수 있습니다. 그러나 비 클러스터형 인덱스와 마찬가지로 너무 많으면 쓰기 속도가 느려집니다.

필자의 경험에 따르면 읽기에서 좋은 결과를 얻을 수 있지만 테이블이 복제에 관련된 경우 특별히 쓰기 (삽입 및 업데이트)를 모니터링해야합니다.

그러나 귀하의 주요 관심사를 이해하고 the null values있으므로 색인의 SPARSE 열을 제안합니다 .

희소 열은 필터링 된 인덱스에 특히 적합 합니다.

희소 열을 광고 했으므로 제한 사항에 대해서도 말하지 않으면 기분이 좋지 않습니다.

스파 스 열이있는 테이블을 디자인 할 때 행이 업데이트 될 때 테이블의 널이 아닌 스파 스 열마다 추가 2 바이트의 오버 헤드가 필요합니다.

그 결과

추가 메모리 요구 사항,이 메모리 오버 헤드를 포함하여 총 행 크기가 8019를 초과하면 오류 576으로 업데이트가 예기치 않게 실패 할 수 있습니다.

행에서 열을 푸시 할 수 없습니다.

bigint 유형의 600 개 스파 스 열이있는 테이블의> 예를 고려하십시오.

널이 아닌 열이 571이면 디스크의 총 크기는 571 * 12 = 6852 바이트입니다. 추가 행 오버 헤드와 스파 스 열 머리글을 포함하면 약 6895 바이트로 늘어납니다. 이 페이지는 여전히 디스크에서 약 1124 바이트를 사용할 수 있습니다. 이는 추가 열을 성공적으로 업데이트 할 수 있다는 인상을 줄 수 있습니다. 그러나 업데이트하는 동안 메모리에 2 * (널이 아닌 스파 스 열의 수) 인 추가 오버 헤드가 있습니다. 이 예에서 추가 오버 헤드 (2 * 571 = 1142 바이트)를 포함하면 디스크의 행 크기가 약 8037 바이트로 증가합니다. 이 크기는 최대 허용 크기 인 8019 바이트를 초과합니다. 모든 열은 고정 길이 데이터 형식이므로 행에서 밀어 낼 수 없습니다. 결과적으로 576 오류와 함께 업데이트가 실패합니다.

위의 링크에 대한 자세한 내용은 여기 에이 경고를 게시하는 것이 좋습니다.

스파 스에서 스파 스로 또는 스파 스에서 스파 스로 열을 변경하려면 열의 저장소 형식을 변경해야합니다.

SQL Server 데이터베이스 엔진은 다음 절차를 사용하여이 변경을 수행합니다.

1-새 스토리지 크기 및 형식으로 테이블에 새 열을 추가합니다.

2-테이블의 각 행에 대해 이전 열에 저장된 값을 업데이트하고 새 열로 복사합니다.

3-테이블 스키마에서 이전 열을 제거합니다.

4-테이블을 다시 작성하거나 (클러스터형 인덱스가없는 경우) 클러스터형 인덱스를 다시 작성하여 이전 열에서 사용한 공간을 회수합니다.