MySQL에서는 동일한 열에 여러 개의 인덱스를 생성할 수 있습니다. 의도했든 의도하지 않았든 MySQL은 중복 인덱스를 별도로 유지해야 하며, 최적화 프로그램도 쿼리를 최적화할 때 이를 하나씩 고려해야 하므로 성능에 영향을 미칩니다.
중복 인덱스는 동일한 컬럼에 동일한 순서로 생성된 동일한 유형의 인덱스를 의미하며, 이러한 방식으로 중복 인덱스를 생성하는 것을 피하고 발견 후 즉시 삭제해야 합니다. 그러나 다양한 쿼리 요구 사항을 충족하기 위해 동일한 열에 다양한 유형의 인덱스를 만드는 것이 가능합니다.
CREATE TABLE test( ID INT NOT NULL PRIMARY KEY, A INT NOT NULL, B INT NOT NULL, UNIQUE(ID), INDEX(ID), ) ENGINE=InnoDB;
이 SQL은 3개의 중복 인덱스를 생성합니다. 일반적으로 이렇게 할 이유가 없습니다.
중복 인덱스와 중복 인덱스에는 약간의 차이가 있습니다. 인덱스(a, b)를 생성한 후 인덱스(a)를 생성하면 이는 이전 인덱스의 접두사 인덱스일 뿐이므로 중복 인덱스입니다. (a, b)도 (a)와 같이 사용할 수 있지만 (b, a)는 중복 인덱스가 아니며, 인덱스 (b)도 아닙니다. b는 인덱스 (a, b)의 가장 왼쪽 접두사 열이 아니기 때문입니다. 또한 동일한 열에 다른 유형의 인덱스(예: 해시 인덱스 및 전체 텍스트 인덱스)를 생성하면 해당 인덱스 열에 관계없이 B-Tree 인덱스에 대한 중복 인덱스가 되지 않습니다.
중복 인덱스는 일반적으로 테이블에 새 인덱스를 추가할 때 발생합니다. 예를 들어, 이후 인덱스(A)를 확장하는 대신 새 인덱스(A,B)를 추가할 수 있습니다. 또 다른 상황은 인덱스를 (A, ID)로 확장하는 것입니다. 여기서 ID는 기본 키입니다. InnoDB의 경우 기본 키가 이미 보조 인덱스에 포함되어 있으므로 이것도 중복됩니다.
대부분의 경우 새 인덱스를 생성하는 대신 기존 인덱스를 확장해야 합니다. 그러나 기존 인덱스를 확장하면 인덱스가 너무 커져서 성능에 영향을 미치기 때문에 성능을 고려하여 중복 인덱스가 필요한 경우도 있습니다. 인덱스를 사용하는 다른 쿼리 예: 정수 열에 인덱스가 있고 이제 인덱스를 확장하기 위해 매우 긴 varchar 열을 추가해야 하는 경우, 특히 이 인덱스를 포함 인덱스로 사용하는 쿼리가 있는 경우 성능이 급격히 떨어질 수 있습니다. 또는 이것이 myisam 테이블이고 범위 쿼리가 많을 때(myisam의 접두사 압축으로 인해)
예를 들어 userinfo 테이블이 있습니다. 이 테이블에는 1,000,000개의 레코드가 있으며 각 state_id 값에 대해 약 20,000개의 레코드가 있습니다. state_id에 인덱스가 있고 다음 SQL을 호출합니다. Q1
SELECT count(*) FROM userinfo WHERE state_id=5; --Q1
수정된 쿼리의 실행 속도는 초당 115회(QPS)입니다
또 다른 SQL도 있는데 Q2
SELECT state_id,city,address FROM userinfo WHERE state_id=5; --Q2
이 쿼리의 QPS는 10입니다. 인덱스 성능을 향상시키는 가장 간단한 방법은 인덱스가 쿼리를 포함할 수 있도록 인덱스를 (state_id, city, address)로 사용하는 것입니다:
ALERT TABLE userinfo ADD KEY state_id_2(state_id,city,address);
(참고 : state_id에는 이미 인덱스가 있습니다. 네, 이전 개념으로는 중복 인덱스가 아닌 중복 인덱스입니다)
1. Shlomi Noach의 common_schema에서 몇 가지 시도를 사용할 수 있습니다. common_schema는 일반적으로 사용되는 일련의 저장소이며 서버에 설치할 수 있습니다.
2. 테이블 구조를 분석하여 중복 및 중복 인덱스를 찾는 Percona Toolkit의 pt_duplicate-key-checker를 사용할 수 있습니다.
위 내용은 mysql의 중복 및 중복 인덱스 정보의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!