Mysql 피복 대 합성 대 열 인덱스

Mysql 피복 대 합성 대 열 인덱스

다음 쿼리에서

SELECT  col1,col2
FROM    table1
WHERE   col3='value1'
  AND   col4='value2'

만약 제가 col3와 col4에 두 개의 개별 인덱스를 가지고 있다면, 어떤 것이 이 쿼리에 사용됩니까?

쿼리의 각 테이블에 대해 하나의 인덱스만 사용된다는 것을 어딘가에서 읽었습니다.쿼리가 두 인덱스를 모두 사용할 수 있는 방법이 없다는 의미입니까?

둘째, 만약 제가 col3와 col4를 함께 사용하여 composite index를 만들었지만 WHERE 조항에서 col3만 사용한다면 성능이 더 나빠질까요?예:

SELECT  col1,col2
FROM    table1
WHERE   col3='value1'

마지막으로, 모든 경우에 커버링 인덱스만 사용하는 것이 더 나을까요? 그리고 MYISAM과 innodb 스토리지 엔진 간에 차이가 있습니까?

피복 지수가 합성 지수와 같지 않습니다.

만약 제가 col3와 col4에 두 개의 개별 인덱스를 가지고 있다면, 어떤 것이 이 쿼리에 사용됩니까?

카디널리티가 가장 높은 인덱스입니다.
MySQL은 어떤 인덱스가 어떤 속성을 갖는지에 대한 통계를 보관합니다.
MySQL의 통계에서 알 수 있듯이 가장 판별력이 높은 지수가 사용됩니다.

쿼리의 각 테이블에 대해 하나의 인덱스만 사용된다는 것을 어딘가에서 읽었습니다.쿼리가 두 인덱스를 모두 사용할 수 있는 방법이 없다는 의미입니까?

하위 선택을 사용할 수 있습니다.
또는 col3와 col4를 모두 포함하는 복합 지수를 사용하는 것이 더 좋습니다.

둘째, 만약 제가 col3와 col4를 함께 사용하여 composite index를 만들었지만 WHERE 조항에서 col3만 사용한다면 성능이 더 나빠질까요?예:

는 입니다.compound인덱스, 합성 아님.
컴파운드 인덱스의 가장 왼쪽 부분만 사용됩니다.
그래서 만약 지수가 다음과 같이 정의된다면,

index myindex (col3, col4)  <<-- will work with your example.
index myindex (col4, col3)  <<-- will not work. 

참조: http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html

맨 왼쪽 필드를 선택하면 where 절에서 인덱스의 해당 부분을 사용하지 않아도 됩니다.
요가 .

Myindex(col1,col2)

SELECT col1 FROM table1 WHERE col2 = 200  <<-- will use index, but not efficiently
SELECT * FROM table1 where col2 = 200     <<-- will NOT use index.  

이것이 작동하는 이유는 첫번째 쿼리가 커버링 인덱스를 사용하고 검색을 수행하기 때문입니다.
두 번째 쿼리는 테이블에 액세스해야 하며 이러한 이유로 인덱스가 의미가 없지만 스캔해야 합니다.
InnoDB에서만 작동합니다.

란란입니까?
커버링 인덱스는 쿼리에서 선택된 모든 필드가 다음과 같은 경우를 말합니다.covered인덱스에 따라 InnoDB(MyISAM이 아님)는 테이블의 데이터를 읽지 않고 인덱스의 데이터만 사용하여 선택 속도를 크게 높입니다.
InnoDB에서 기본 키는 모든 보조 인덱스에 포함되므로 모든 보조 인덱스는 복합 인덱스입니다.
이는 InnoDB에서 다음 쿼리를 실행하는 경우를 의미합니다.

SELECT indexed_field FROM table1 WHERE pk = something

MySQL은 항상 커버링 인덱스를 사용하고 실제 테이블에 액세스하지 않습니다. 커버링 인덱스를 사용할 수 있지만 선호할 것입니다.PRIMARY KEY한 줄만 치기만 하면 되기 때문입니다.

I upvoted Johan's answer for completeness, but I think the following statement he makes regarding secondary indexes is incorrect and/or confusing;

Note that in InnoDB the primary key is included in all secondary indexes, 
so in a way all secondary indexes are compound indexes.

This means that if you run the following query on InnoDB:

SELECT indexed_field FROM table1 WHERE pk = something

MySQL will always use a covering index and will not access the actual table.

While I agree the primary key is INCLUDED in the secondary index, I do not agree MySQL "will always use a covering index" in the SELECT query specified here.

To see why, note that a full index "scan" is always required in this case. This is not the same as a "seek" operation, but is instead a 100% scan of the secondary index contents. This is due to the fact the secondary index is not ordered by the primary key; it is ordered by "indexed_field" (otherwise it would not be much use as an index!).

In light of this latter fact, there will be cases where it is more efficient to "seek" the primary key, and then extract indexed_field "from the actual table," not from the secondary index.

This is a question I hear a lot and there is a lot of confusion around the issues due to:

• The differences in mySQL over the years. Indexes and multiple index support changed over the years (towards being supported)

• the InnoDB / myISAM differences There are some key differences (below) but I do not believe multiple indexes are one of them

저의 ISAM은 나이가 많지만 검증이 되었습니다.MyISAM 테이블의 데이터는 테이블 형식, 데이터 및 인덱스에 대해 세 개의 서로 다른 파일로 분할됩니다.
InnoDB는 MyISAM보다 비교적 최신이며 트랜잭션이 안전합니다.InnoDB는 또한 다중 사용자 동시성과 성능을 향상시키는 테이블 잠금 대신 행 잠금 기능을 제공합니다.InnoDB에는 외부 키 제약 조건도 있습니다.
InnoDB는 행 잠금 기능 때문에 고부하 환경에 적합합니다.

반드시 explain_plan을 사용하여 쿼리 실행을 분석해야 합니다.

복합 지수가 복합 지수와 같지 않습니다.

• 합성 지수는 필터, 조인 및 선택 기준의 모든 열을 다룹니다.이 모든 열은 인덱스 B-tree 전체에 걸쳐 모든 인덱스 페이지에 저장됩니다.
• 복합 인덱스는 B-트리의 모든 필터 및 조인 키 열을 포함하지만 선택한 열은 검색되지 않으므로 리프 페이지에만 유지되며 추출만 수행됩니다!이렇게 하면 공간이 절약되고 인덱스 페이지가 적게 생성되므로 I/O가 빨라집니다.

언급URL : https://stackoverflow.com/questions/8213235/mysql-covering-vs-composite-vs-column-index