현재보기를 사용하는 대신 하드 테이블을 사용해야합니까?

Question

나는 현재 논쟁하고 있는지 여부는 다음 표에 의해 형성 뷰 내 테이블, mapping_uGroups_uProducts :

CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` 
    SQL SECURITY DEFINER VIEW `db`.`mapping_uGroups_uProducts` 
    AS select distinct `X`.`upID` AS `upID`,`Z`.`ugID` AS `ugID` from 
    ((`db`.`mapping_uProducts_Products` `X` join `db`.`productsInfo` `Y` 
      on((`X`.`pID` = `Y`.`pID`))) join `db`.`mapping_uGroups_Groups` `Z` 
      on((`Y`.`gID` = `Z`.`gID`))); 

나의 현재 쿼리는 다음과 같습니다 꽤 느린

SELECT upID FROM uProductsInfo \ 
     JOIN fs_uProducts USING (upID) column \ 
     JOIN mapping_uGroups_uProducts USING (upID) -- could be faster if we use hard table and index \ 
     JOIN mapping_fs_key USING (fsKeyID) \ 
    WHERE fsName="OVERALL" \ 
     AND ugID=1   \ 
    ORDER BY score DESC  \ 
    LIMIT 0,30; 

. (30 개의 결과는 약 10 초가 필요함). 내 쿼리가 너무 느린 이유는 특정 쿼리가 쿼리 속도에 의존하지 않는 VIEW에 의존한다는 사실 때문입니다. (가) 여기에 설명

+----+-------------+----------------+--------+----------------+---------+---------+---------------------------------------+-------+---------------------------------+ 
     | id | select_type | table   | type | possible_keys | key  | key_len | ref         | rows | Extra       | 
     +----+-------------+----------------+--------+----------------+---------+---------+---------------------------------------+-------+---------------------------------+ 
     | 1 | PRIMARY  | mapping_fs_key | const | PRIMARY,fsName | fsName | 386  | const         |  1 | Using temporary; Using filesort | 
     | 1 | PRIMARY  | <derived2>  | ALL | NULL   | NULL | NULL | NULL         | 19706 | Using where      | 
     | 1 | PRIMARY  | uProductsInfo | eq_ref | PRIMARY  | PRIMARY | 4  | mapping_uGroups_uProducts.upID  |  1 | Using index      | 
     | 1 | PRIMARY  | fs_uProducts | ref | upID   | upID | 4  | db.uProductsInfo.upID     | 221 | Using where      | 
     | 2 | DERIVED  | X    | ALL | PRIMARY  | NULL | NULL | NULL         | 40772 | Using temporary     | 
     | 2 | DERIVED  | Y    | eq_ref | PRIMARY  | PRIMARY | 4  | db.X.pID        |  1 | Distinct      | 
     | 2 | DERIVED  | Z    | ref | PRIMARY  | PRIMARY | 4  | db.Y.gID        |  2 | Using index; Distinct   | 
     +----+-------------+----------------+--------+----------------+---------+---------+---------------------------------------+-------+---------------------------------+ 
     7 rows in set (0.48 sec) 

꽤 비밀보고, 내가보기 드롭 그냥 하드 테이블에보기에 모든 것을 삽입하는 스크립트를 작성해야하는지 여부를 알 수 없습니다. (매핑이 자주 변경되기 때문에 분명히 뷰의 유연성을 잃을 것입니다).

스키마를 어떻게 최적화 할 수 있습니까?

Answer 1

는 현재 계획은 구동 테이블과 뷰를 사용하여 당신 :이 fsName = 'OVERALL'

와 mapping_fs_key의 각 레코드를 검사하여이 기능 뷰를 대체 할 수있는 :

SELECT upID FROM uProductsInfo 
JOIN fs_uProducts USING (upID) 
JOIN mapping_fs_key USING (fsKeyID) 
WHERE fsName='OVERALL' 
     AND upID IN 
     (
     SELECT upID 
     FROM mapping_uGroups_Groups Z 
     JOIN productsInfo Y 
     ON  y.gID = z.gID 
     JOIN mapping_uProducts_Products X 
     ON  x.pID = y.pID 
     WHERE z.ugID = 1 
     ) 
ORDER BY 
     score DESC 
LIMIT 0,30