2016-06-29 3 views
-1

인덱스 테이블을 도울 수 있습니까?아마 나쁜 인덱스, 전체 테이블 스캔

문제는 내가 내 테이블을 인덱스,하지만 난 여전히 "전체 테이블 스캔"을 가지고 내 설명

이 내 (작업) 쿼리하지만 큰 테이블에 속도가 느릴 수 있었다, 나는 잘 모릅니다 변경하려면

EXPLAIN select * from stats_clicked s 
join visitor v on s.visitor_id=v.id 

ps INDEX3 - 나는 많은 시간 값을 wan't 해달라고 (1,5) 때 방문자 = 내가 위에서 한 일을 수행 할 경우 5

CREATE TABLE `visitor` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `visited_time` int(11) DEFAULT NULL, 
    PRIMARY KEY (`id`) 
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; 

CREATE TABLE `stats_clicked` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `visitor_id` int(11) NOT NULL, 
    `page_clicked_id` int(11) DEFAULT NULL, 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `index3` (`visitor_id`,`page_clicked_id`), 
    KEY `index1` (`visitor_id`) 
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; 


insert into visitor (`visited_time`) values 
(1467122944),(1467122944),(1467122944), 
(1467122944),(1467122944),(1467122944), 
(1467122944),(1467122944),(1467122944), 
(1467122944),(1467122944),(1467122944), 
(1467122944),(1467122944),(1467122944); 

insert into `stats_clicked` (`visitor_id`,`page_clicked_id`) values 
(1,47),(2,24),(3,83),(3,8),(3,85),(3,88),(4,57), 
(5,2),(6,1),(7,28),(8,83),(9,11),(9,16),(9,1),(10,17), 
(11,70),(12,73),(13,97),(14,57),(15,30),(15,2),(15,22); 
+0

무엇이 실수입니까? 당신은 무엇을 할 수 없습니까? – Fredster

+0

'(visitor_id, page_clicked_id)'가 유일하고 받아 들여지지 않기를 바란다면 visitor_id = 1과 page_clicked_id = 5 ** 여러 번 – Fredster

+0

테이블을 인덱싱 할 때 스키마가 올바르지 않습니다. 하지만 내 설명에 여전히 "전체 테이블 스캔"을 가지고 있습니다 –

답변

0

, 나는

EXPLAIN select * from stats_clicked s 
join visitor v on s.visitor_id=v.id 
+----+-------------+-------+------+---------------+--------+---------+--------------------+------+-------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref    | rows | Extra  | 
+----+-------------+-------+------+---------------+--------+---------+--------------------+------+-------------+ 
| 1 | SIMPLE  | v  | ALL | PRIMARY  | NULL | NULL | NULL    | 15 | NULL  | 
| 1 | SIMPLE  | s  | ref | index3,index1 | index3 | 4  | so_gibberish2.v.id | 1 | Using index | 
+----+-------------+-------+------+---------------+--------+---------+--------------------+------+-------------+ 

그러나 얻을 = ID로 1 새로 고침 페이지

truncate table visitor; 

insert into visitor (`visited_time`) values 
(1467122944),(1467122944),(1467122944), 
(1467122944),(1467122944),(1467122944), 
(1467122944),(1467122944),(1467122944), 
(1467122944),(1467122944),(1467122944), 
(1467122944),(1467122944),(1467122944); 

insert into visitor (`visited_time`) values 
(1467122945),(1467122945),(1467122945), 
(1467122945),(1467122945),(1467122945), 
(1467122945),(1467122945),(1467122945), 
(1467122945),(1467122945),(1467122945), 
(1467122945),(1467122945),(1467122945), 


insert into visitor (`visited_time`) values 
(1467122946),(1467122946),(1467122946), 
(1467122946),(1467122946),(1467122946), 
(1467122946),(1467122946),(1467122946), 
(1467122946),(1467122946),(1467122946), 
(1467122946),(1467122946),(1467122946), 
(1467122946),(1467122946),(1467122946), 
(1467122946),(1467122946),(1467122946), 
(1467122946),(1467122946),(1467122946), 
(1467122946),(1467122946),(1467122946), 
(1467122946),(1467122946),(1467122946), 
(1467122946),(1467122946),(1467122946), 
(1467122946),(1467122946),(1467122946); 

insert visitor(`visited_time`) select `visited_time` from visitor; 
insert visitor(`visited_time`) select `visited_time` from visitor; 
insert visitor(`visited_time`) select `visited_time` from visitor; 
insert visitor(`visited_time`) select `visited_time` from visitor; 
insert visitor(`visited_time`) select `visited_time` from visitor; 
insert visitor(`visited_time`) select `visited_time` from visitor; 
insert visitor(`visited_time`) select `visited_time` from visitor; 
insert visitor(`visited_time`) select `visited_time` from visitor; 
insert visitor(`visited_time`) select `visited_time` from visitor; 
insert visitor(`visited_time`) select `visited_time` from visitor; 
insert visitor(`visited_time`) select `visited_time` from visitor; 

select count(*) from visitor; 
-- 104448 rows 

하지 테이블 스캔 결과 :

012 그때 많은 양의 데이터의 다음의 하중을 잘라야하는 경우 (100K 이상의 행으로 결말) 3,516,
EXPLAIN select * from stats_clicked s 
join visitor v on s.visitor_id=v.id; 

+----+-------------+-------+--------+---------------+---------+---------+----------------------------+------+-------------+ 
| id | select_type | table | type | possible_keys | key  | key_len | ref      | rows | Extra  | 
+----+-------------+-------+--------+---------------+---------+---------+----------------------------+------+-------------+ 
| 1 | SIMPLE  | s  | index | index3,index1 | index3 | 9  | NULL      | 22 | Using index | 
| 1 | SIMPLE  | v  | eq_ref | PRIMARY  | PRIMARY | 4  | so_gibberish2.s.visitor_id | 1 | NULL  | 
+----+-------------+-------+--------+---------------+---------+---------+----------------------------+------+-------------+ 

이유는 매뉴얼 페이지 How MySQL Uses Indexes에 나열되어 있습니다 :

인덱스가 작은 테이블, 또는 쿼리를보고 큰 테이블에 대한 조회에 덜 중요한 대부분 또는 모든 행을 처리합니다. 쿼리가 대부분행에 액세스해야하는 경우 순차적으로 읽기가 인덱스 을 사용하는 것보다 빠릅니다. 순차 읽기는 디스크 검색을 최소화합니다. 단, 행 모두가 쿼리에 필요하지는 않습니다.

위에 나열된 이유. 귀하의 질문에, 당신은 그것을 가치가 색인을 만들기위한 행이 너무 적었습니다. 따라서 db 엔진은 작은 테이블에서 인덱스를 사용하지 않는 빠른 방법을 선택했습니다.

+0

부여 된 "테이블 스캔"은 아니지만 "인덱스 스캔"입니다. . –

+0

나는 15 개의 인서트가 아닌 적절한 데이터로 '설명'한다고 믿어야한다. – Drew

0

stats_clickedid이 필요하지 않습니다. 사실, 그 존재는 그 테이블로 모든 가능한 질의를 늦춘다. More details.