SELECT 문이 possible_keys를 사용하지 않음

Question

기본 키가없는 레거시 시스템의 테이블이 있습니다. 공장에서 자재를 발행하기위한 거래 데이터를 기록합니다.

간단히하기 위해 각 행에 job_number, part_number, quantity & date_issued가 포함되어 있다고 가정 해 보겠습니다.

날짜 발급 된 열에 인덱스를 추가했습니다. 나는 date_issued이> '20100101', 그것은이 보여 WHERE이 issued_parts로부터 SELECT *를 EXPLAIN 실행하면 :

 
+----+-------------+----------------+------+-------------------+------+---------+------+---------+-------------+ 
| id | select_type | table   | type | possible_keys  | key | key_len | ref | rows | Extra  | 
+----+-------------+----------------+------+-------------------+------+---------+------+---------+-------------+ 
| 1 | SIMPLE  | issued_parts | ALL | date_issued_alloc | NULL | NULL | NULL | 9724620 | Using where | 
+----+-------------+----------------+------+-------------------+------+---------+------+---------+-------------+ 

은 그래서 키를 볼 수 있지만, 그것을 사용하지 않는 이유는 무엇입니까? 누군가 설명 할 수 있습니까?

Answer 1

MySQL Query Optimizer가 올바르게 결정되었습니다.

다음은 어떻게 표시되는지입니다. 다음을 실행합니다 : 당신이 실제로 검색되는 행의 수는 테이블의 총 수는 MySQL의 5 %를 초과하는 경우 행이 쿼리

SELECT COUNT(1) FROM issued_parts WHERE date_issued > '20100101'; 

일치의

SELECT COUNT(1) FROM issued_parts; 

카운트 행

카운트 Query Optimizer는 전체 테이블 스캔을 수행하는 것이 더 적은 노력이라고 결정합니다. 쿼리가 더 정확한, 예를 들어,이와 있다면

이제 :

SELECT * FROM issued_parts WHERE date_issued = '20100101'; 

다음, 당신은 다른 전부 계획을 EXPLAIN 얻을 것이다.

Answer 2

possible_keys 관련 키가있는 키는 이름이 있지만 키의 각 키가 쿼리에 유용하다는 의미는 아닙니다. 이 경우 아무 것도 없습니다.

Answer 3

인덱스에는 여러 가지 유형 (인덱스?)이 있습니다. 해시 인덱스는 특정 값이 지정된 항목에 대한 빠른 검색 방법입니다. 당신이 (예를 들어, 10 개의 날짜의 목록)에 대해 쿼리하고있는 신중한 값들을 가지고 있다면, 그 값들 각각에 대한 해시를 계산할 수 있고, 인덱스에서 찾아 볼 수 있습니다. 특정 값에 대한 조회를 수행하지 않고 비교를 수행하기 때문에 해시 색인이 도움이되지 않습니다.

반면 B- 트리 색인은 색인 작성중인 요소에 순서를 지정하기 때문에 사용자를 도울 수 있습니다. 예를 들어, mysql (B-Tree 인덱스 특성 검색)에 대해서는 http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html을 참조하십시오. 테이블이 색인 열에 b-tree 색인을 사용하고 있는지 확인할 수 있습니다.