현재 데이터베이스를 최적화하는 데 시간을 할애하고 있습니다.
나는 특별히 인덱스를보고있다.
몇 가지 질문이 있습니다.
- 너무 많은 인덱스가 있습니까?
- 인덱스의 속도를 높이는 것은 무엇입니까?
- 인덱스가 느려지는 것은 무엇입니까?
- 색인을 추가하는 것이 좋은 생각은 언제입니까?
- 색인을 추가하는 것이 언제 나쁜 생각입니까?
- 다중 인덱스 대 다중 열 인덱스의 장단점?
답변
인덱스의 속도를 높이는 것은 무엇입니까?
데이터 검색-SELECT 문.
인덱스가 느려지는 것은 무엇입니까?
데이터 조작-INSERT, UPDATE, DELETE 문.
색인을 추가하는 것이 좋은 생각은 언제입니까?
더 나은 데이터 검색 성능을 원할 경우.
색인을 추가하는 것이 언제 나쁜 생각입니까?
데이터 조작이 많은 테이블에서 삽입, 업데이트 …
다중 인덱스 대 다중 열 인덱스의 장단점?
쿼리는 포함 인덱스 (두 개 이상의 열에 대한 인덱스)를 처리 할 때 인덱스 열 정의에서 왼쪽에서 오른쪽으로 열 순서를 처리해야합니다. 명령문의 열 순서는 중요하지 않습니다. 열 1, 2 및 3의 순서 만 중요합니다. 인덱스를 사용하려면 명령문에 열 1에 대한 참조가 있어야합니다. 열 2 또는 3에 대한 참조 만있는 경우 1/2/3에 대한 커버링 인덱스를 사용할 수 없습니다.
MySQL에서는 쿼리의 SELECT / 문당 하나의 인덱스 만 사용할 수 있습니다 (서브 쿼리 / 등은 별도의 문으로 표시됨). 그리고 MySQL이 허용하는 테이블 당 공간의 양에 제한이 있습니다. 또한 인덱싱 된 열에서 함수를 실행하면 인덱스가 쓸모 없게됩니다-IE :
WHERE DATE(datetime_column) = ...
답변
이 질문에 대한 일부 답변에 동의하지 않습니다.
너무 많은 인덱스가 있습니까?
물론이야. 쿼리에서 사용하지 않는 인덱스를 만들지 마십시오. 중복 인덱스를 생성하지 마십시오. pt-duplicate-key-checker 및 pt-index-usage 와 같은 도구를 사용 하여 필요하지 않은 인덱스를 검색 할 수 있습니다.
인덱스의 속도를 높이는 것은 무엇입니까?
- WHERE 절의 검색 조건입니다.
- 조인 조건.
- ORDER BY의 일부 사례.
- GROUP BY의 일부 사례.
- UNIQUE 제약.
- FOREIGN KEY 제약.
- FULLTEXT 검색.
다른 답변은 인덱스가 많을수록 INSERT / UPDATE / DELETE가 느리다고 조언했습니다. 사실이지만 UPDATE 및 DELETE의 많은 사용에는 WHERE 절이 있으며 MySQL에서는 UPDATE 및 DELETE도 JOIN을 지원한다는 점을 고려하십시오. 인덱스는 인덱스 업데이트의 오버 헤드를 보충하는 것보다 이러한 쿼리에 더 많은 이점을 줄 수 있습니다.
또한 InnoDB는 UPDATE 또는 DELETE의 영향을받는 행을 잠급니다. 그들은 이것을 행 수준 잠금이라고 부르지 만 실제로는 인덱스 수준 잠금입니다. 검색 범위를 좁힐 인덱스가없는 경우 InnoDB는 변경중인 특정 행보다 더 많은 행을 잠 가야합니다. 테이블의 모든 행을 잠글 수도 있습니다 . 이러한 잠금은 논리적으로 충돌하지 않더라도 다른 클라이언트의 변경 사항을 차단합니다.
색인을 추가하는 것이 좋은 생각은 언제입니까?
위의 경우 중 하나에서 인덱스의 이점을 얻을 수있는 쿼리를 실행해야하는 경우.
색인을 추가하는 것이 언제 나쁜 생각입니까?
인덱스가 다른 기존 인덱스의 왼쪽 접두사이거나 인덱스가 실행해야하는 쿼리에 도움이되지 않는 경우.
다중 인덱스 대 다중 열 인덱스의 장단점?
경우에 따라 MySQL은 인덱스 병합 최적화를 수행 하고 독립적 인 인덱스 검색의 결과를 통합하거나 교차 할 수 있습니다. 그러나 인덱스 병합을 수행 할 필요가 없도록 단일 인덱스를 정의하는 것이 더 나은 성능을 제공합니다.
컨설팅 고객 중 한 명을 위해 인덱스가없는 다 대다 테이블에 다중 열 인덱스를 정의하고 조인 쿼리를 9,400 만 배나 개선했습니다!
최적화해야하는 쿼리를 기반으로 올바른 인덱스를 디자인하는 것은 복잡한 프로세스 입니다. “모든 항목 색인화”또는 “업데이트 속도 저하를 피하기 위해 아무것도 색인화하지 않음”과 같은 광범위한 규칙을 만들어서는 안됩니다.
내 프레젠테이션 How to Design Indexes, Really를 참조하십시오 .
답변
너무 많은 인덱스가 있습니까?
인덱스는 당면한 문제 (테이블, 애플리케이션이 실행할 쿼리 등)에 따라 알려야합니다.
인덱스의 속도를 높이는 것은 무엇입니까?
선택.
인덱스가 느려지는 것은 무엇입니까?
인덱스를 업데이트해야하므로 INSERT 속도가 느려집니다.
색인을 추가하는 것이 좋은 생각은 언제입니까?
애플리케이션에 다른 WHERE 절이 필요한 경우.
색인을 추가하는 것이 언제 나쁜 생각입니까?
고유성 제약 조건을 쿼리하거나 적용하는 데 필요하지 않을 때.
다중 인덱스 대 다중 열 인덱스의 장단점?
질문을 이해하지 못합니다. 여러 열을 포함하는 고유성 제약 조건이있는 경우 반드시 그렇게 모델링하십시오.
답변
너무 많은 인덱스가 있습니까?
예. 색인을 만들려고 나가지 말고 필요에 따라 만듭니다.
인덱스의 속도를 높이는 것은 무엇입니까?
인덱스 테이블 / 뷰에 대한 모든 쿼리.
인덱스가 느려지는 것은 무엇입니까?
각 새 레코드를 인덱싱해야하므로 인덱싱 된 테이블에 대한 모든 INSERT 문은 느려집니다.
색인을 추가하는 것이 좋은 생각은 언제입니까?
쿼리가 허용 가능한 속도로 실행되지 않을 때. 클러스터 된 PK의 일부가 아닌 레코드를 필터링 할 수 있습니다.이 경우 검색중인 필터를 기반으로 인덱스를 추가해야합니다 (성능이 적합하다고 판단되는 경우).
색인을 추가하는 것이 언제 나쁜 생각입니까?
당신이 그것을 위해 그것을 할 때 -즉 과도한 최적화.
다중 인덱스 대 다중 열 인덱스의 장단점?
개선하려는 쿼리에 따라 다릅니다.
답변
너무 많은 인덱스가 있습니까?
예, 모든 것과 마찬가지로 인덱스가 너무 많으면 데이터 조작 속도가 느려집니다.
색인을 추가하는 것이 좋은 생각은 언제입니까?
인덱스를 추가하는 좋은 방법은 쿼리가 너무 느린 경우입니다 (즉, 쿼리에 조인이 너무 많음). 성능을 조정하려면 솔리드 모델을 빌드 한 후에 만이 최적화를 사용해야합니다.
답변
