나는 여러 열이있는 테이블을했습니다 UNIQUE인덱스 _job_id__와 __keyword_id__.
해당 열에서 __job_id__자주 수행되는 쿼리가있는 경우 다른 인덱스를 추가해야 GROUP BY합니까?
(1 억 행에서 시간이 걸릴 수 있습니다. 바로 내가하는 대신 묻는 것입니다)
답변:
아니, 전혀 아니다! 필요한 메인 열이 인덱스에서 가장 왼쪽에 있으면 MySQL Query Optimizer가 올바른 작업을 수행합니다. 이러한 인덱스를 만든 경우 GROUP BY job_id, keyword_id를 항상 수행하면 MySQL Query Optimizer가 해당 인덱스를 사용하지 않도록 선택할 수 있습니다. job_id로만 레코드를 수집하는 경우 MySQL Query Optimizer가 인덱스를 사용하거나 사용하지 않을 수 있지만 어쨌든 중복 인덱스 공간이 낭비됩니다.
테이블이 MyISAM 인 경우 이러한 인덱스를 작성하면 MYI 파일이 부풀려집니다.
테이블이 InnoDB이고 innodb_file_per_table이 0 인 경우 이러한 인덱스를 만들면 ibdata1이 부풀려집니다.
테이블이 InnoDB이고 innodb_file_per_table이 1 인 경우 인덱스를 만들면 테이블의 .ibd 파일이 부풀려집니다.
요약하면 추가 색인을 만들 필요는 없습니다 !!!
인덱스는 정렬group by 을 줄여야 만 작업 속도를 높일 수 있습니다. 사용 된 인덱스 가 클러스터형 인덱스 이거나 최소한 클러스터형 인덱스 와 동일한 선행 열이있는 경우 더 효율적 입니다. 이 모든 hash group by것에서 MySQL은 일반적으로 인덱스의 이점을 전혀 우회 하는 작업에 해당하지 않는다고 가정 합니다. 아마도 다른 사람이 이것을 확인할 수 있습니다.
절의 job_id유일한 열 group by이고 클러스터 된 인덱스가 아니라고 가정 할 때 별도의 인덱스를 사용 하면 약간의 이점 이 있습니다. 인덱스가 더 작아서 스캔하면 I / O가 줄어 듭니다.
--편집하다--
인덱스으로 보조 인덱스에없는 클러스터 된 인덱스 키에 대해 정의 된 모든 기본 키 필드를 포함 ,에 대한 인덱스는 job_id에서만 인덱스보다 작은 것입니다 job_id, keyword_id경우 keyword_id클러스터 된 인덱스의 일부가 아닙니다.