아래 쿼리를 참조하십시오. 쿼리가 인덱스를 사용하고 임시 및 파일 공유를 사용하지 않도록 테이블에서 어떤 인덱스를 만들어야합니까? 나는 색인의 많은 다른 조합을 시도하고 advice here을 읽지 만, 나는 그것을 이해하는 것처럼 보일 수 없다. 설명이 Using Where (색인 없음)이거나 Using Where Using Temporary, Using Filesort그룹화/주문을위한 MySQL 인덱스
간략한 설명입니다. 모든 열은 정수입니다. 경험에 의해
SELECT c1, Sum(c2)
FROM table
WHERE c3 IS NOT NULL
AND c4 = 2011
AND c5 = 0
AND c6 In (6,9,11)
GROUP BY c1
도움이 될 것입니다. 다음과 같이 쿼리를 다시 작성 :
SELECT c1, Sum(c2)
FROM table
WHERE c4 = 2011
AND c5 = 0
AND c6 In (6,9,11)
AND c3 IS NOT NULL
GROUP BY c1
c3을 쿼리의 끝으로 이동시키는 이유는 다음과 같습니다. 예를 들어, c3은 0과 100 사이의 값을 취할 수 있다고 가정합니다 (또는 NULL 일 수 있음). "IS NOT NULL"쿼리를 실행하면 Mysql은 NULL에 해당하는 가장자리를 제외하고 거의 모든 B-Tree 인덱스를 트래버스해야합니다. 따라서 MySQL은 전체 테이블 스캔이 인덱스의 모든 다른 경로를 통과하는 것보다 쉬운 옵션임을 결정합니다. 반면, 쿼리가 "IS NULL"이고 인덱스가 (c3, c4, c5, c6)이면 Mysql이이 인덱스를 사용한다는 것을 알 수 있습니다. 이 경우 Mysql은 NULL 값에 해당하는 인덱스 트리의 일부만 탐색해야하기 때문입니다.
MySQL이 필요로하는 인덱스의 종류는 문제의 쿼리에 크게 의존합니다. @louis가 제안한 것처럼 모든 열에 인덱스를 만드는 것은 좋은 생각이 아닙니다!
자세한 설명 주셔서 감사합니다! – bradvido
"인덱스의 열은 WHERE 절의 열과 동일한 순서로 나타나야합니다. 그렇지 않으면 인덱스가 작동하지 않습니다." 쿼리 옵티마이 저는'WHERE' 절이 어떻게 정렬되는지는 신경 쓰지 않습니다. '선택 ...FROM foo where bar = 1 AND baz <5'는'SELECT ... FROM foo WHERE baz <5 AND bar = 1'와 똑같은 실행 계획을 가지고 똑같은 방식으로 인덱스를 사용합니다. 조건의 유형 (평등 또는 불평등, 선택적 또는 부적합)은 WHERE 절에 나타나는 것이 아니라 중요한 부분입니다. – Air
이것이 사실 인 지 잘 모르겠습니다. 내 경험에 비추어 볼 때 인덱스 정의의 순서는 중요하지만 where 절의 순서는 중요하지 않습니다. –
, 내가 말을해야 : (여기되지 C6을하지만)은 "여기서"절에 모든 열에 대해 인덱스를 구축
이 적어도, C4와 C5.
"group by"절이 결과를 정렬합니다. 결과에 많은 레코드가 있다면 c1을 너무 인덱스 화하는 것이 유용 할 수 있습니다.
c3은 "not null"로만 테스트됩니다. 그러나 인덱싱을 사용하여 항목을 향상시킬 수도 있습니다. 이는 테스트해야합니다.
호프 이것은 도움이되었습니다.
이 문제는 'ORDER BY 2 DESC'절과 관련이 있다고 생각합니다. c2가 색인 된 경우에도 SUM (C2)은 그렇지 않습니다.
당신이 가지고 있어야하는 색인은 데이터에 따라 다르므로 나는 정말로 논평 할 수 없습니다.
인수를 위해, 내가 ORDER BY 절을 사용하지 않는다고 가정 해 봅시다. (나는 질문에서 그것을 제거했다). 나는 여전히 색인을 찾을 수 없습니다. – bradvido
MySQL은 테이블 당 하나의 인덱스 만 사용할 수 있으므로 GROUP BY를 최적화하기 위해 인덱스에 인덱스를두면 WHERE 절이 최적화되지 않아 궁극적으로 더 많은 작업이 발생하므로 스스로를 해칠 수도 있습니다. 완료 (즉, 전체 테이블 스캔). –
GROUP BY와 WHERE 절에서 모두 사용할 수있는 단일 인덱스를 만들 수있는 방법이 있습니까? – bradvido