MySQL-모든 필드를 색인화하지 않는 이유는 무엇입니까?


107

최근에 인덱스의 경이로움을 알게되었고 성능이 크게 향상되었습니다. 그러나 내가 배운 모든 것으로이 질문에 대한 답을 찾을 수없는 것 같습니다.

인덱스는 훌륭하지만 테이블을 엄청나게 빠르게 만들기 위해 모든 필드를 인덱싱 할 수없는 이유는 무엇입니까? 이 작업을하지 않는 좋은 이유가 있다고 확신하지만, 30 필드 테이블에 세 개의 필드는 어떻습니까? 30 필드에 10? 어디에 선을 그려야하며, 그 이유는 무엇입니까?


7
인덱스 된 1 만 개가 넘는 항목이있는 테이블에 값을 삽입 해보십시오. 모든 항목은 삽입 / 삭제로 인해 업데이트되어야합니다. 이는 엄청난 시간 오버 헤드이며 각 값에 인덱스가있는 경우 메모리 오버 헤드가 다소 발생합니다
Jesus Ramos

5
공간 및 쓰기 성능 외에 한 가지 이유가 더 있습니다 . 단일 테이블 액세스에 여러 인덱스를 사용 하는 것은 매우 비효율적 입니다. 즉, 각 열에 하나의 인덱스가 있더라도 WHERE 절에서 여러 열에 액세스하면 선택 성능이 좋지 않습니다. 이 경우 다중 열 인덱스가 가장 좋습니다.
Markus Winand 2011

1
30 개의 필드가있는 테이블이있는 경우 테이블 구조를 실제로 살펴 봐야합니다. 그들은 함께 일하기가 매우 어려울 것입니다.

답변:


122

인덱스는 메모리 (RAM)에서 공간을 차지합니다. 인덱스가 너무 많거나 너무 크면 DB가 인덱스를 디스크와 교환해야합니다. 또한 삽입 및 삭제 시간이 늘어납니다 (각 인덱스는 삽입 / 삭제 / 업데이트 된 모든 데이터에 대해 업데이트되어야 함).

당신은 무한한 기억이 없습니다. 모든 인덱스가 RAM에 맞도록 만드는 것이 좋습니다.

무한한 시간이 없습니다. 인덱싱해야하는 열만 인덱싱하면 삽입 / 삭제 / 업데이트 성능 저하가 최소화됩니다.


11
일반적인 이해를 제공하는 좋은 캐주얼 대답이지만 실제로 인덱스에 선을 그릴 위치를 결정하는 데는별로 도움이되지 않습니다. 어떻게 알 수 있습니까? 일반적으로 WHERED 필드에 추가하고 최선을 다하기를 바랍니다.
Andrew

@Andrew 1 년 반 후 질문에 대한 답을 찾았습니까?
Sinjai

1
@Sinjai 일반적으로 어디에 열을 추가하는 것은 아마도 좋은 경험 법칙입니다. 그러나 그렇지 않으면 당신이 인덱스에 대한 전문가가되고 싶다면 많은 독서를 할 수 있습니다. 예. stackoverflow.com/questions/3049283/…
Andrew

디스크 공간을 잊지 마십시오.
jpmc26

27

모든 인덱스는 행이 업데이트, 삽입 또는 삭제 될 때마다 업데이트되어야합니다. 따라서 인덱스가 많을수록 쓰기 작업의 성능이 저하됩니다.

또한 모든 인덱스는 추가 디스크 공간과 메모리 공간 (호출시)을 차지하므로 읽기 작업도 잠재적으로 느려질 수 있습니다 (대형 테이블의 경우). 이것 좀 봐


6
링크는 MS SQL Server 용입니다 . 이 질문은 MySQL에
OMG Ponies 2011 년

5
@OMG 링크에서 점의 대부분은 모든 주요 RDBMS에 적용
RichardTheKiwi

5
@Richard aka cyberkiwi : 인덱스는 ANSI에서 다루지 않습니다. 각 공급 업체가 유사한 용어를 사용하는 것은 기적입니다. 그러나 그럼에도 불구하고 SQL Server와 MySQL만이 "클러스터형"및 "비 클러스터형"인덱스라는 용어를 사용합니다. 이는 SQL Server에서 MySQL보다 더 많은 것을 의미합니다. 한 공급 업체에 대한 권장 사항이 다른 공급 업체에 적용되어야한다는 보장은 없습니다.
OMG Ponies 2011 년

3
@omg 처음 6 개 포인트는 모든 dbms에 적용됩니다. 비 / 클러스터링 된 항목을 건너 뛰고 아래에는 일반 인덱싱과 관련된 더 많은 포인트가 있습니다. 지적하고 싶은 특정 사항이 있으면 전화하십시오. 그렇지 않으면 댓글 (삭제 된 답변 포함)에서 아무도 귀하의 평가에 동의하지 않는 모든 답변을 부정하는 것처럼 보입니다.
RichardTheKiwi

10

CRUD 요구 사항의 균형을 맞춰야합니다. 테이블 쓰기가 느려집니다. 선을 그릴 위치는 데이터가 액세스되는 방식 (정렬 필터링 등)에 따라 다릅니다.


또한 모든 인덱스는 데이터베이스 공간을 차지합니다
Acanthus 2011 년

@Acanthus : 사용 가능한 가장 작은 하드 드라이브는 기가 바이트 단위로 측정됩니다 .
OMG Ponies 2011 년

4
@OMG이지만 Brian이 지적한 것처럼 RAM은 아닙니다. 필요한 것보다 더 많이 저장하는 것은 결코 좋은 생각 이 아닙니다 . RAM, 백업 미디어 (테이프 당 적합한 버전 등)의 데이터 / 인덱스 캐싱은 모두 쓸모없는 인덱스에 의해 영향을받습니다
RichardTheKiwi

9
풍부한 자원은 낭비 나 비효율의 이유가 아닙니다.
Smandoli 2011 년

6
사실이지만 제약은 10 년 이상 전과는 다릅니다.
OMG Ponies 2011 년

2

인덱싱은 드라이브와 램 모두에서 더 많은 할당 된 공간을 차지하지만 성능도 많이 향상됩니다. 불행히도 메모리 제한에 도달하면 시스템이 드라이브 공간을 포기하고 성능이 저하됩니다. 실제로는 삽입이나 검색 (WHERE 절)이 아닌 어떤 종류의 데이터 순회 알고리즘과도 관련이 없다고 생각할 수있는 필드를 인덱싱해서는 안됩니다. 하지만 그렇지 않다면해야합니다. 기본적으로 모든 필드를 인덱싱해야합니다. 인덱싱 해제를 고려해야하는 필드는 속도가 필요한 경우를 제외하고 중재자 만 쿼리를 사용하는 경우입니다.


2

이 대답은 제 개인적인 의견입니다. 저는 수학 논리를 사용하여 대답합니다.

두 번째 질문은 멈출 경계에 관한 것이 었습니다. 먼저 몇 가지 수학적 계산을 해보겠습니다. 모든 필드를 인덱싱하면 테이블에 L 필드가있는 N 개의 행이 있다고 가정하면 모든 테이블이 정렬되는 L 개의 새 인덱스 테이블이 생성됩니다. 의미있는 방식으로 인덱스 필드의 데이터, 테이블이 W 가중치이면 언뜻보기에 W * 2가 될 것입니다 (1 테라가 2 테라가 됨) 큰 테이블이 100 개 있으면 (나는 이미 테이블 번호가있는 프로젝트에서 작업했습니다. arround 1800 table)이 공간의 100 배 (100 테라)를 낭비하게됩니다.

모든 테이블에 인덱스를 적용 할 경우 인덱스 업데이트에 대해 생각해야합니다. 하나의 업데이트 트리거가 모든 인덱스 업데이트입니다.

이 시나리오에서 이번에 느슨해지면 선택이나 업데이트에서 손실하는 것이 바람직하다는 결론을 내립니다. 인덱싱되지 않은 필드를 선택하면 모든 필드에서 다른 선택을 트리거하지 않기 때문입니다. 색인화되지 않음

무엇을 색인할까요?

foreign-keys : 필수

primary-key : 누군가이 글을 읽는 것이이 사건에 도움이 될 수 있을지 아직 확실하지 않습니다.

다른 필드 : 첫 번째 자연 답변은 나머지 필드의 절반입니다. 이유 : 더 많은 색인을 생성해야하는 경우 r 더 적은 색인을 생성해야하는 경우 최상의 답변과 멀지 않습니다. 우리는 색인이 나쁘고 모든 색인이 생성되었음을 알기 때문에 멀지 않습니다. 나쁘다.

이 세 가지 점에서 K 키로 구성된 L 필드가있는 경우 한계는 ((L-K)/2)+KL / 10 정도에 가까운 어딘가에 있어야한다는 결론을 내릴 수 있습니다.

이 대답은 내 논리와 개인적인 원칙에 근거합니다.


1

테이블의 모든 열을 인덱싱하는 것은 좋지 않습니다. 이렇게하면 테이블을 매우 빠르게 읽을 수 있지만 쓰기 속도도 훨씬 느려집니다. 모든 열이 인덱싱 된 테이블에 기록하려면 해당 테이블에 새 레코드를 넣은 다음 각 열의 정보를 자체 인덱스 테이블에 넣는 작업이 포함됩니다.


특히 데이터 테이블이 100MB에 불과하지만 index.table이 300MB 이상인 경우 테이블을 빠르게 읽을 수 있는지 확실하지 않습니다.
David

당신이 말한 모든 것은 전에 언급되었습니다.
Vael Victus
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.