Actuellement en utilisant View, Dois-je utiliser une table dure à la place?

Question

Je discute actuellement si ma table, mapping_uGroups_uProducts, qui est une vue formée par le tableau suivant:

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`))); 

Ma requête en cours est:

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; 

qui est assez lent. (pour 30 résultats, cela prend environ 10 secondes). Je pense que la raison pour laquelle ma requête est si lente est certainement due au fait que cette requête particulière repose sur une VIEW qui n'a pas d'index pour accélérer les choses.

+----+-------------+----------------+--------+----------------+---------+---------+---------------------------------------+-------+---------------------------------+ 
     | 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) 

L'expliquer ici semble assez cryptique, et je ne sais pas si je devrais laisser tomber vue et écrire un script pour insérer simplement tout dans la vue à une table difficile. (évidemment, il perdra la flexibilité de la vue puisque la cartographie change assez fréquemment).

Quelqu'un a-t-il une idée de comment optimiser mon schéma?

Answer 1

Vous plan actuel utilise la vue comme une table conduit: il est analysé pour chaque enregistrement mapping_fs_key avec fsName = 'OVERALL'

Vous pouvez remplacer la vue avec cette fonction:

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