데이터베이스에 하나의 삽입 만있는 경우 가능한 모든 열 조합을 색인화하는 것이 좋지 않습니까?

23

큰 선택 쿼리가 필요하지만 한 번만 채워지는 데이터베이스를 기반으로하는보고 시스템에서 작업하고 있습니다. 데이터베이스 관리 시스템은 Microsoft SQL Server 2017입니다. 이와 같은 시스템을 설계하는 더 좋은 방법이있을 수 있지만 이론적으로 접근 해 봅시다.

이론적으로 말하면 :

데이터베이스가 매우 큰 경우 (여러 테이블에서 150M + 행)
그리고 데이터베이스가 한 번만 채워질 것이라고 가정 할 수 있습니다.

가능한 모든 열 조합을 인덱싱하면 선택 쿼리에 부정적인 성능 영향을 줄 수 있습니까?

— Lopsided
소스

4

가능한 모든 조합은 대부분 비실용적입니다. 보다 합리적인 접근 방식은 수동으로 그러나 매우 관대하게 색인을 작성하는 것입니다. 그것은 확실히 이해 될 수 있습니다.

— usr

12

제목이나 굵은 글씨로 일관된 단어를 다시 작성해보십시오. 한눈에 나는 가장 높은 투표 응답 "예"에 혼란스러워했다

— aaaaaa

150M 개의 행은 단일 테이블의 경우 크지 만 데이터베이스의 경우에는 크지 않습니다. 실제로,보고 시스템은 가능한 소수의 열 조합 만 사용하므로 최소한 초기에 주요 조합에 초점을 맞춘 다음 필요에 따라 더 복잡하게하는 것이 가장 좋습니다.

— pojo-guy

36

예, 옵티마이 저가 고려해야 할 데이터에 대한 추가 액세스 경로가 많으므로 초기 계획 컴파일 시간에 영향을 미칩니다.

SQL Server 2017을 사용 중이고 한 번로드하고 보고서를 실행하는 대신 클러스터 된 열 저장소 인덱스를 대신 사용하지 않는 이유는 무엇입니까?

가능한 모든 열 조합을 색인화 해야하는 이상적인 솔루션 인 것 같습니다.

열 저장소 인덱스-개요

— 에릭 달링
소스

Columnstore는 내가 갈 곳이지만, 궁금합니다. 최적화가 설명 한 것과 정반대로 작동하지 않습니까? 사용 가능한 인덱스를 검색하는 대신 유용한 "어떻게"라는 말은 쿼리를 예를 들어 해당 쿼리에 대한 완벽한 인덱스를 "생각"하지 않는지, 존재하는지 확인합니다. (그렇지 않으면 누락 된 인덱스 메시지가 생성됩니다.) 내가 맞다면 (모르고 추측 만하면) 인덱스가 많더라도 몇 개가있는 것보다 눈에 띄게 더 긴 시간은 아닙니다. 그들의.

— Limonka

26

테이블에 N 개의 열이있는 경우 가능한 모든 열 조합은 2 ^ N-1입니다 (빈 세트 제거). 1023 개의 인덱스를 의미하는 10 개의 열의 경우 20 개의 열의 경우 1048575 개의 인덱스가 만들어집니다. 대부분의 인덱스는 사용되지 않지만 옵티마이 저가 고려해야합니다. 옵티마이 저가 더 나은 인덱스 대신 차선책 인덱스를 선택할 수 있습니다. 실제로 어떤 인덱스가 유용한 지 알아 내려고 노력하는 대신 모든 종류의 인덱스를 생성하는 길을 택하지는 않을 것입니다.

수정 가능한 색인 수 수정

Jeff가 지적한 것처럼 (3,2,1)은 (1,2,3)과 분명히 다르기 때문에 2 ^ N (전력 설정)보다 훨씬 나쁩니다. N 열의 경우 N 열의 모든 열을 포함하는 인덱스의 첫 번째 위치를 선택할 수 있습니다. N-1 방식 등의 두 번째 위치에 대해 우리는 N으로 끝납니다! 전체 크기의 다른 인덱스. 이 인덱스의 다른 인덱스는이 세트의 다른 인덱스에 포함되지 않습니다. 또한 더 짧은 색인을 추가하여 전체 색인에 포함되지 않습니다. 따라서 인덱스 수는 N!입니다. 그러므로 10 개의 열에 대한 예는 10이됩니다! = 3628800 인덱스 및 20 (드럼 롤) 2432902008176640000 인덱스. 이것은 엄청나게 큰 숫자입니다. 각 색인에 대해 1mm의 부품을 1 점씩 넣으면 모든 점을 통과하는 데 94 일이 걸립니다. 모두와 dont ;-)

— 레나르트
소스

6

더 나쁜 것은 인덱스의 열 순서가 중요 할 수 있다는 것입니다. 따라서 최대 N을 얻습니다! 색인.

— Jeff

2

그러나 다른 인덱스의 접두사 인 인덱스는 필요하지 않습니다.

— Barmar

3

더 나빠요 모든 인덱스에 대해 ASC 및 DESC 조합이 있습니다.

— ypercubeᵀᴹ

2

훨씬 더 나쁜 것은 INCLUDE 인덱스가 있다는 것입니다.

— ypercubeᵀᴹ

2

그리고 많은 부분 인덱스가 있습니다.

— ypercubeᵀᴹ

7

아니.

"모든 것"을 색인하는 것은 실용적이지 않지만 "가장 많이"색인 할 수 있습니다.

여기 있습니다. 테이블에 N열 이 있으면 가능한 인덱스 수는 N!입니다. 테이블에 열이 10 개 있다고 가정하면 10가능한 인덱스는 없지만 10!. 즉 ...입니다 3628800 하나의 테이블에 .... 많은 디스크 공간, 디스크 I / O, 캐시 및 탐색 시간입니다.

왜? 몇 가지 이유 :

Lightwwight 색인은 일반적으로 캐시되어 빛을 빠르게 만듭니다. 3 백만 개가 있으면 캐시되지 않습니다.
SQL 옵티마이 저는 특히 조인을 사용할 때 어느 것이 더 나은지를 결정하는 데 많은 시간이 걸릴 수 있습니다.
SQL 최적화 프로그램은 포괄적 인 알고리즘 사용을 포기하고 대신 휴리스틱 알고리즘을 시도 할 수 있습니다. 이것은 "최적의 것보다 적을"수 있습니다. 예를 들어 PostgreSQL에는 "8보다 작은 테이블 쿼리"및 "8보다 많은 테이블 쿼리"에 대해 서로 다른 옵션이 있습니다.
인덱스는 힙보다 가벼워 야합니다. 모든 것을 인덱싱하는 경우 인덱스는 힙만큼 무거워집니다. 인덱스의 목적을 어기는 것입니다.

— 임 팔러
소스

숫자가 2 ^ 10 아닌가요? 각 열은 주어진 색인에서 포함되거나 제외됩니다. 주문이 중요합니까?

— RemcoGerlich

2

@RemcoGerlich 예, 주문이 중요합니다.

— ypercubeᵀᴹ

2

아니요, 아마도 SELECT쿼리에 부정적인 영향을 미치지는 않지만

디스크 사용량이 많아집니다.
비용 이 크게 증가합니다 INSERT.
대부분의 지수는 사용되지 않습니다.
많은 WHERE조건식은 여전히 더 복잡한 색인을 사용하지 않습니다.
필요한 인덱스의 개수는 열 개수에 따라 기하 급수적으로 증가합니다. 즉, 예를 들어 8 개의 열이있는 경우 가능한 모든 조합에 대해 256 개의 인덱스가 필요합니다.

— 피터는 모니카 복직을 말한다
소스

컴파일 시간에 문제가 발생할 수 있습니다.

— Erik Darling

@sp_BlitzErik 앱의 ORM을 생각하십니까?

— peterh는 모니카

아니요, 내 대답을 참조하십시오.

— Erik Darling

@sp_BlitzErik 와우, 반가워요!

— 피터는 모니카