인덱스 크기를 줄임으로써 MySQL 성능이 향상됩니까?

Question

테이블에 ~ 1.2m 행이 있습니다. URL이 포함 된 varchar (255) 필드 하나를 포함하여 6 개의 열이 인덱싱됩니다.

URL이 테이블에 있는지, 따라서 인덱스에 있는지 확인하려면 테이블을 스캔 할 수 있어야하지만 인덱스 크기를 약 50 줄여 성능을 향상시킬 수 있는지 궁금합니다.

물론 이것은 데이터베이스의 URL을 검색 할 때 더 많은 행을 검색해야 할 수도 있음을 의미합니다.하지만이 쿼리는 매 30 초마다 한 번 수행하면되므로 더 작은 인덱스 크기는 가치가있을 것입니다. 생각?

Answer 1

두 가지 이유 메모리에 캐시 가능. 성능 히트를 볼 때 (모든 새로운 하드웨어 사양으로 ... 1.2M 행의 가능성은 거의 없지만 여전히 주목할 가치가 있습니다).

2) 많은 'n'문자만으로 각 레코드를 신속하게 식별 할 수 있습니다. 255 자 전체를 색인 할 필요가 없을 수도 있습니다. 당신은 상관하지 않는 이유

두 가지 이유 -

1) 언급 한 바와 같이, 당신은 당신의 인덱스 키 버퍼에서로 성장 보지, 왜 걱정 않을 수도 있습니다.

2) 첫 번째 'n'문자를 결정해야하며 그 후에도 성능은 전체 색인보다 작거나 같아야합니다. 당신은 정말로 그것에 시간을 할애해야합니까? 정확성의 손실 가능성이 있습니까? 내 SQL indexing tutorial (covers MySQL as well)에서

Answer 2

인덱스 크기는 디스크 공간에만 문제가 있으므로 심각한 문제가 발생하지 않을 것입니다.

색인이 있거나없는 것은 CRUD 작업을 기반으로 할 수 있으며 더 많은 선택 또는 더 많은 삽입/업데이트/삭제가 있습니까?

Answer 3

처음 50 자만 사용하도록 색인을 변경하면 어떤 차이가 있는지 의심 스럽습니다.

VARCHAR 열이므로 색인 된 값은 각 URL만큼 길기 때문에 일반적인 URL을 보면 URL 당 50 자 정도만 색인을 생성 할 수 있습니다.

URL이 모두 상당히 길더라도 색인 크기를 줄이면 색인의 해당 부분이 이미 메모리에있을 확률이 높아질 수 있지만 다시 차이가 있음을 알 수 있습니다. 이것은 매우 높은 볼륨이었고 추가 성능을 위해 마이크로 최적화를 시작해야하는 경우에만 유용 할 수 있습니다. 색인 크기가 어느 정도 성장 그래서 거기에 아마 드문 가능성이 완전히 아니라고,

1) 인덱스가 메모리에로드되는 너무 (색인을 가정 할 때 유용합니다) - 왜 어쩌면 더 낮추는

Answer 4

:

팁 : 항상 인덱스에 원본 데이터를 목표로하고 있습니다. 색인에 넣을 수있는 가장 유용한 정보는 종종 입니다.

이것은 다른 원칙을 수행 할 매우 강력한 이유가있을 때까지는 일반적으로 권장하는 규칙입니다.

대부분의 경우 공간이 문제되지 않습니다.

성능을 고려할 때 인덱스 트리 깊이는 인덱스 리프 노드 수와 함께 로그 적으로 증가합니다. 즉, 인덱스 크기를 절반으로 줄이는 것은 아마도 트리 깊이를 전혀 줄이지 않는다는 것을 의미합니다. 따라서 성능 이득은 개선 된 캐시 적중률로 제한 될 수 있습니다. 하지만 30 초에 한 번씩 쿼리를 실행한다고하셨습니다. 적당히로드 된 머신에서는 색인이 전혀 캐시되지 않는다는 것을 의미합니다 (30 초마다 동일한 URL을 검색하는 경우는 제외).

결국 : 위에서 언급 한 일반적인 조언에 반대하는 이유가 없습니다.

인덱스 공간을 실제로 저장하려는 경우 중복 인덱스 (예 : 동일한 열로 시작하는 인덱스)를 먼저 찾으십시오. 이들은 일반적으로 낮은 매달린 과일입니다.

Answer 5

길이가 32 고정 된 URL의 md5 해시를 유지하십시오.