데이터 공간보다 인덱스 공간이 큰 것은 나쁜가요?

종종 올바른 인덱스가없는 큰 테이블에 대해 쿼리를 실행해야합니다. 그래서 DBA에게 그러한 인덱스를 만들도록 요청합니다. 그가하는 첫 번째 일은 테이블 통계를보고 인덱스 공간 크기를 보는 것입니다.

종종 그는 "인덱스가 이미 테이블보다 크기 때문에"다른 대안을 찾도록 지시 할 것입니다. 그는 인덱스가 데이터보다 작아야한다고 생각합니다. "책에서 색인을 본 적이 있습니까? 책 자체보다 훨씬 작으며 이것이 바로 테이블 색인이되는 방법"이라고 말했기 때문입니다.

나는 그의 철학이 옳다고 생각하지 않지만, 그는 DBA를 이끌고 개발자이기 때문에 도전 할 수 없다. 쿼리에 인덱스가 필요한 경우 읽을 수없고 유지 관리 할 수없는 SP를 만드는 "해결 방법"을 찾는 대신 인덱스를 만들어야합니다.

필요한 열만 선택하고 있습니다. 문제는 날짜별로 필터링하므로 엔진이 열과 일치하도록 테이블 스캔을 수행해야한다는 것입니다. 쿼리는 통계를 수집하기 위해 하루에 한 번 밤에 실행되지만 실행하는 데 15 분이 걸립니다 (또 다른 단단하고 빠른 규칙이 있습니다. 절차는 3 분 이상 걸리지 않습니다).

DBA는 나에게 인덱스 통계를 보여 주었다. 해당 테이블에는 약 10 개의 인덱스가 있으며 그 중 6 개만 사용되었습니다 (통계는 4 개에 0으로 표시됨). 이 시스템은 20 명 이상의 개발자가 참여하는 대규모 시스템입니다. 어떤 이유로 든 색인이 작성되어 더 이상 사용되지 않을 수 있습니다.

테스트 DB가 실행되므로 SQL Server 2008을 지원해야합니다. 그러나 고객은 모두 2014 년과 2016 년입니다.

인덱스 디자인을 슬라이딩 스위치처럼 생각하십시오. 이 빨간색 삼각형 스위치 노브를 원하는 선을 따라 원하는 위치로 이동할 수 있습니다.

나는 보통 크기로 측정하지 않습니다-나는 보통 색인 수량으로 생각하지만 크기도 좋습니다.

DBA가 스위치가 오른쪽으로 너무 멀리 있다고 생각하는 것 같습니다. 색인을 너무 많이 추가했으며 삭제 / 업데이트 / 삽입이 너무 느리게 수행되고 있습니다.

스위치의 위치에 대해 논쟁하는 대신 많은 인덱스로 인해 발생한 성능 문제에 대해 물어보십시오. 사용자가 삭제 / 업데이트 / 삽입 속도에 대해 불평하거나 잠금 대기 중이거나 크기 때문에 데이터베이스를 백업하는 데 어려움을 겪고있을 수 있습니다.

필자의 시작점은 일반적으로 5와 5입니다. 테이블 당 약 5 개의 인덱스가 있고 인덱스 당 약 5 개 이하의 필드가 있습니다. 그 숫자에 대해서는 마법이 없습니다. 그것은 각 손에 5 개의 손가락이 있다는 사실에서 나옵니다. 따라서 손을 잡고 규칙을 설명하기가 쉽습니다.

작업 부하가 삭제 / 업데이트 / 삽입 작업에 치우쳐 있고 하드웨어 성능이 충분하지 않은 경우 5보다 많은 LESS 인덱스가 필요할 수 있습니다.

워크로드가 대부분 읽기 전용이거나 하드웨어에 많은 투자를 할 때 (전체 데이터베이스를 메모리에 캐시하고 모든 솔리드 스테이트 스토리지를 포함하는 경우) 더 많은 인덱스를 가질 수 있습니다.

또한 테이블에 "The Ozar 5"인덱스보다 더 많은 것을 원한다는 것은 아마도 테이블에 많은 종류의 읽기 무거운 쿼리가 있다는 것을 나타냅니다 .

어느 아마 표시 는 클러스터 또는 클러스터되지 않은 혜택을 누릴 수 columnstore 인덱스 테이블에.

N 개의 서로 다른 액세스 경로 각각에 대해 최적의 인덱스를 가지지 않고 columnstore는 초고속 스캔 기능과 불필요한 열 및 행 세그먼트를 건너 뛸 수있는 기능을 제공합니다. 따라서 초 임계 트랜잭션에 대해 적은 수의 BTree 인덱스를 보유하고 다른 모든 항목은 컬럼 스토어로 대체 할 수 있습니다.

Columnstore 인덱스는 SQL Server 2016+에서 OLTP가 많은 워크로드에서 작동하도록 설계되었습니다. 실시간 운영 분석 설명서를 참조하십시오 .

나는 브렌트의 답변을 좋아하고 그것을 찬성했습니다. 그래도 다른 관점을 추가하고 싶습니다. 나는 사용자, 개발자 및 DBA로 일했으며 의견이 관련이 없다고 생각합니다. 쿼리 수행 방법과 결과를 얻는 데 걸리는 시간을 결정하는 것은 사용자 (또는 이해 관계자)의 몫이라고 생각합니다. 그런 다음이를 위해 개발자와 DBA가 협력해야합니다.

회사의 DBA 직책이이 주제를 '담당자'인 경우 쿼리를 분석하고 더 나은 쿼리 디자인에 대한 제안을하거나 성능에 대한 답변을 얻을 수 있습니다.

쿼리 및 / 또는 데이터 구조를 수정하여 목표를 달성 할 수 없다면 세 가지 선택이 있다고 생각합니다.

1. 느린 데이터 검색
2. 느린 데이터 업데이트
3. 더 많은 하드웨어 리소스 $$$$

물론 모든 상황에는 여러 비즈니스 및 기술 요소에 따라 많은 변수가 있지만 세 가지 옵션이 모든 경우에 해당하는 것은 아니라고 생각합니다.

인덱스> 테이블을 금지하기에는 너무 엄격한 것 같습니다. 테이블이 거의 변경되지 않거나 (또는 ​​리소스에 대한 경쟁이 많지 않은 밤에 변경되는 경우) 다양한 방법으로 많이 쿼리되는 경우 많은 큰 인덱스를 정당화 할 수 있습니다. DBA는 또한 자신의 코가 소속되지 않은 곳에 붙어 있지 않도록주의해야합니다. 그가 당신 / 당신의 시스템에 기가 바이트를 제한한다면, 그는 그 공간이 어떻게 사용되는지 너무 신경 쓰지 않아야합니다. 그가 과로하면 이것이 이유 일 수 있습니다.

그러나 고려해야 할 사항이 많이 있습니다.

• 인덱스가 많으면 삽입 / 업데이트 / 삭제 속도가 느려집니다. 따라서 테이블이 많이 바뀌면 너무 많이 만들지 않도록주의하십시오.
• 공간도 문제가 될 수 있습니다. 기가 바이트는 돈이 들기 때문에 (현재는 그리 많지 않음) 백업이 수행되는 방식에 따라 백업 속도가 느려지는 시간도 있습니다.
• 거의 또는 전혀 사용되지 않는 인덱스를 찾기 위해 대부분의 심각한 데이터베이스를 모니터링 할 수 있습니다. 그들 중 일부를 버리는 것을 고려하십시오.
• 때로는 색인이 필요하다고 생각하지만 쿼리를 더 자세히 조사하면 동일한 결과와 색인이 필요없이 다르게 조정하고 다시 작성할 수 있습니다. Explain Plan을 사용하여 색인 사용 여부를 확인하십시오.
• 때때로 성능 저하없이 여러 열 인덱스에서 마지막 열을 삭제할 수 있습니다. 때로는 인덱스 스토리지 공간이 작고 주어진 시간에 더 많은 인덱스가 메모리에 유지 / 캐싱되기 때문에 쿼리 속도가 더 빨라질 수도 있습니다.
• 함수 기반 인덱스는 일반 인덱스를 대체하여 더 많은 공간을 절약 할 수 있습니다. 예 : 전체 성을 쿼리하는 대신 처음 두 글자도 ( where substr(surname, 1, 2) = substr(<userinput>, 1, 2) and surname=<userinput>) 및을 쿼리하십시오 create index i on customers(substr(surname,1,2)). 이것은 충분히 빠를 수 있으며 색인은 더 작아집니다.
• 데이터베이스는 다양한 유형의 인덱스를 지원합니다. 일부 유형은 다른 유형보다 공간을 덜 사용합니다. 어쩌면 일부 색인을 공간을 덜 소비하는 유형으로 변환 할 수 있습니까? 먼저 다양한 색인 유형과 이들이 어떤 상황에 좋고 나쁜지 이해해야합니다.
• 빈번한 일괄 작업이 특정 인덱스를 필요로하는 유일한 작업 인 경우 해당 일괄 작업에 대해서만 해당 인덱스를 생성 한 다음 삭제하십시오.