MySQL보기는 항상 전체 테이블 스캔을 수행합니까?
https://stackoverflow.com/questions/637328
-
10-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
MySQL 5.1에서보기를 사용하는 쿼리를 최적화하려고합니다. 보기에서 1 열을 선택하더라도 항상 전체 테이블 스캔을 수행하는 것 같습니다. 그것이 예상되는 행동입니까?
보기는 아래의 첫 번째 쿼리에 지정된 테이블에 대해 "이 테이블의 모든 열 - *아님"입니다.
이것은보기를 구성하는 쿼리에서 인덱스 된 열 프로모션을 선택할 때의 설명 출력입니다. 보시다시피보기의 출력과는 크게 다릅니다.
EXPLAIN SELECT pb.PromotionID FROM PromotionBase pb INNER JOIN PromotionCart pct ON pb.PromotionID = pct.PromotionID INNER JOIN PromotionCode pc ON pb.PromotionID = pc.PromotionID WHERE pc.PromotionCode = '5TAFF312C0NT'\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: pc
type: const
possible_keys: PRIMARY,fk_pc_pb
key: PRIMARY
key_len: 302
ref: const
rows: 1
Extra:
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: pb
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: const
rows: 1
Extra: Using index
*************************** 3. row ***************************
id: 1
select_type: SIMPLE
table: pct
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: const
rows: 1
Extra: Using index
3 rows in set (0.00 sec)
같은 것을 선택할 때의 출력이지만보기에서
EXPLAIN SELECT vpc.PromotionID FROM vw_PromotionCode vpc WHERE vpc.PromotionCode = '5TAFF312C0NT'\G;
*************************** 1. row ***************************
id: 1
select_type: PRIMARY
table: <derived2>
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 5830
Extra: Using where
*************************** 2. row ***************************
id: 2
select_type: DERIVED
table: pcart
type: index
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: NULL
rows: 33
Extra: Using index
*************************** 3. row ***************************
id: 2
select_type: DERIVED
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.pcart.PromotionID
rows: 1
Extra:
*************************** 4. row ***************************
id: 2
select_type: DERIVED
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 5. row ***************************
id: 3
select_type: UNION
table: pp
type: index
possible_keys: PRIMARY
key: pp_p
key_len: 4
ref: NULL
rows: 1
Extra: Using index
*************************** 6. row ***************************
id: 3
select_type: UNION
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.pp.PromotionID
rows: 1
Extra:
*************************** 7. row ***************************
id: 3
select_type: UNION
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 8. row ***************************
id: 4
select_type: UNION
table: pcp
type: index
possible_keys: PRIMARY
key: pcp_cp
key_len: 4
ref: NULL
rows: 1
Extra: Using index
*************************** 9. row ***************************
id: 4
select_type: UNION
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.pcp.PromotionID
rows: 1
Extra:
*************************** 10. row ***************************
id: 4
select_type: UNION
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 11. row ***************************
id: 5
select_type: UNION
table: ppc
type: index
possible_keys: PRIMARY
key: ppc_pc
key_len: 4
ref: NULL
rows: 1
Extra: Using index
*************************** 12. row ***************************
id: 5
select_type: UNION
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.ppc.PromotionID
rows: 1
Extra:
*************************** 13. row ***************************
id: 5
select_type: UNION
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 14. row ***************************
id: 6
select_type: UNION
table: ppt
type: index
possible_keys: PRIMARY
key: ppt_pt
key_len: 4
ref: NULL
rows: 1
Extra: Using index
*************************** 15. row ***************************
id: 6
select_type: UNION
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.ppt.PromotionID
rows: 1
Extra:
*************************** 16. row ***************************
id: 6
select_type: UNION
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 17. row ***************************
id: NULL
select_type: UNION RESULT
table: <union2,3,4,5,6>
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: NULL
Extra:
17 rows in set (0.18 sec)
해결책
MySQL의 뷰는 색인화되지 않으므로 그 특성에 의해 액세스 할 때마다 전체 스캔이 필요합니다. 일반적으로 이것은 작은 결과 세트를 반환하는 상당히 복잡한 정적 쿼리가있는 상황에만 뷰가 실제로 유용하며 매번 전체 결과 세트를 가져올 계획입니다.
편집하다: 물론 뷰는 기본 테이블의 인덱스를 사용하여 뷰 자체가 최적화되도록합니다 (그렇지 않으면 전혀 사용하지 않을 것입니다). 뷰에 인덱스가 없기 때문에 쿼리의 쿼리에는 불가능합니다. 최적화 될보기.
뷰에 대한 인덱스를 구성하는 것은 어쨌든 비용이 많이들 것입니다. 왜냐하면 뷰를 프로파일 링하려고 시도하지는 않지만 온도 테이블이 무대 뒤에서 구성되고 결과 세트가 반환 될 것이라고 확신합니다. 임시 테이블을 구성하는 데 이미 많은 시간이 걸리고, 어떤 인덱스가 필요한지 추측하려고 시도하는 견해를 원하지 않습니다. MySQL이 현재 뷰에 사용할 인덱스를 지정하는 메소드를 제공하지 않는 두 번째 포인트를 불러 일으키는 것은 어떤 필드를 색인화 해야하는지 어떻게 알 수 있습니까? 쿼리를 기반으로 추측합니까?
당신은 a를 사용하는 것을 고려할 수 있습니다 임시 테이블 그러면 임시 테이블의 필드에 인덱스를 지정할 수 있기 때문입니다. 그러나 경험에서 이것은 정말로 느리게 경향이 있습니다.
이 모든 견해가 포함되어있는 경우 표 1, 표 2, 표 3에서 모두 선택된 것; 그렇다면 왜이 쿼리가 전혀보기에 있어야하는지 물어봐야 할 것입니까? 어떤 이유로 든 절대적으로 필요한 경우 저장된 절차를 사용하여 쿼리를 캡슐화 한 다음 결과 세트에 대한 데이터베이스에 대한 간단한 호출의 이점을 유지하면서 최적화 된 성능을 얻을 수 있습니다.
다른 팁
나는 그것을 더 깊이 들여다 보았다. 나는 핵심 정보 지점을 놓쳤다.
임시 테이블 알고리즘은 기본 테이블에서 인덱스를 사용할 수 없습니다.
이것은 MySQL의 버그 인 것처럼 보이며 2006 년에 다시보고되었지만 2009 년에는 해결 된 것처럼 보이지 않습니다! http://forums.mysql.com/read.php?100,56681,56681
외부 조인으로 쿼리를 다시 작성해야 할 것 같습니다.
