2

私は現在、次のテーブルによって形成されるビューである私のテーブル、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)

ここでの説明はかなり不可解に見えます。ビューを削除して、ビュー内のすべてをハードテーブルに挿入するスクリプトを作成する必要があるかどうかはわかりません。(マッピングが頻繁に変更されるため、明らかにビューの柔軟性が失われます)。

スキーマをより適切に最適化する方法を知っている人はいますか?

4

1 に答える 1

0

現在の計画では、ビューを駆動テーブルとして使用します: で各レコードがスキャンされmapping_fs_keyますfsName = 'OVERALL'

ビューを次の関数に置き換えることができます。

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
于 2010-05-11T08:32:01.353 に答える