MySql - Innodb - Index/Foreign Keyが壊れています

Question

私は奇妙な状況が続いています。私の夜間の質問の1つは、通常5分かかり、12時間以上かかりました。ここでは、クエリは次のとおりです。

SELECT Z.id, 
     Z.seoAlias, 
     GROUP_CONCAT(DISTINCT LOWER(A.include)) AS include, 
     GROUP_CONCAT(DISTINCT LOWER(A.exclude)) AS exclude 
FROM df_productsbystore   AS X 
INNER JOIN df_product_variants AS Y ON Y.id = X.id_variant 
INNER JOIN df_products   AS Z ON Z.id = Y.id_product 
INNER JOIN df_advertisers  AS A ON A.id = X.id_store 
WHERE X.isActive > 0 
AND Z.id > 60301433 
GROUP BY Z.id 
ORDER BY Z.id 
LIMIT 45000; 

私はEXPLAIN走って、次の得た：私の開発環境に違って見え

+----+-------------+-------+--------+------------------------------------------------------------------------------------+-----------+---------+---------------------+------+---------------------------------+ 
| id | select_type | table | type | possible_keys                  | key  | key_len | ref     | rows | Extra       | 
+----+-------------+-------+--------+------------------------------------------------------------------------------------+-----------+---------+---------------------+------+---------------------------------+ 
| 1 | SIMPLE  | A  | ALL | PRIMARY                   | NULL  | NULL | NULL    | 365 | Using temporary; Using filesort | 
| 1 | SIMPLE  | X  | ref | UNIQUE_variantAndStore,idx_isActive,idx_store          | idx_store | 4  | foenix.A.id   | 600 | Using where      | 
| 1 | SIMPLE  | Y  | eq_ref | PRIMARY,UNIQUE,idx_prod               | PRIMARY | 4  | foenix.X.id_variant | 1 | Using where      | 
| 1 | SIMPLE  | Z  | eq_ref | PRIMARY,UNIQUE_prods_seoAlias,idx_brand,idx_gender2,fk_df_products_id_category_idx | PRIMARY | 4  | foenix.Y.id_product | 1 | NULL       | 
+----+-------------+-------+--------+------------------------------------------------------------------------------------+-----------+---------+---------------------+------+---------------------------------+ 

。 df_advertisersセクションは、私には魚に見えたので、私はX.id_store列に索引を削除して再作成し、現在、TheはEXPLAINこのようになりますと、クエリが高速で再びです：

+----+-------------+-------+--------+------------------------------------------------------------------------------------+------------------------+---------+-------------------+---------+-------------+ 
| id | select_type | table | type | possible_keys                  | key     | key_len | ref    | rows | Extra  | 
+----+-------------+-------+--------+------------------------------------------------------------------------------------+------------------------+---------+-------------------+---------+-------------+ 
| 1 | SIMPLE  | Z  | range | PRIMARY,UNIQUE_prods_seoAlias,idx_brand,idx_gender2,fk_df_products_id_category_idx | PRIMARY    | 4  | NULL    | 2090691 | Using where | 
| 1 | SIMPLE  | Y  | ref | PRIMARY,UNIQUE,idx_prod               | UNIQUE     | 4  | foenix.Z.id  |  1 | Using index | 
| 1 | SIMPLE  | X  | ref | UNIQUE_variantAndStore,idx_isActive,idx_id_store         | UNIQUE_variantAndStore | 4  | foenix.Y.id  |  1 | Using where | 
| 1 | SIMPLE  | A  | eq_ref | PRIMARY                   | PRIMARY    | 4  | foenix.X.id_store |  1 | NULL  | 
+----+-------------+-------+--------+------------------------------------------------------------------------------------+------------------------+---------+-------------------+---------+-------------+ 

それは魔法のようにインデックスように思われます消えた。誰でもこれがどのように可能か説明できますか？このようなことを避けるために、mysqlcheckコマンドなどを定期的に実行することを意味しますか？私は困惑している！

おかげ

Answer 1

次回は、単にそれは非常に速くなり、は問題を解決することがありANALYZE TABLE df_productsbystore;を行います。

ANALYZEは、オプティマイザで始まるためにどのテーブル、この場合には、決定するために依存している統計情報を再計算します。まれな状況では、ステータスが古くなって、慎重にキックが必要です。

警告：私はあなたがやや最近のバージョンではInnoDBを使用していると仮定しています。 MyISAMを使用している場合、より多くの場合、ANALYZEが必要です。

はあなたが本当に45K行が必要ですか？そんなにたくさん何をしますか？

SELECT XYZ.id, XYZ.seoAlias, 
     GROUP_CONCAT(DISTINCT LOWER(A.include)) AS include, 
     GROUP_CONCAT(DISTINCT LOWER(A.exclude)) AS exclude 
    FROM 
    (
     SELECT Z.id, Z.seoAlias, X.id_store 
      FROM df_productsbystore AS X 
      INNER JOIN df_product_variants AS Y ON Y.id = X.id_variant 
      INNER JOIN df_products AS Z   ON Z.id = Y.id_product 
      WHERE X.isActive > 0 
       AND Z.id > 60301433 
      GROUP BY Z.id -- may not be necessary ?? 
      ORDER BY Z.id 
      LIMIT 45000 
    ) AS XYZ 
    INNER JOIN df_advertisers AS A ON A.id = XYZ.id_store 
    GROUP BY ZYZ.id 
    ORDER BY XYZ.id; 

便利なインデックス：

残りを行うには

クエリをスピードアップするための方法は、（おそらく）サブクエリでXとZであなたができることはすべて行うことです、その後、JOIN A私は、インデックス+ FKを削除し、再作成しようとした問題を解決するために

Y: INDEX(id_product, id) 
X: INDEX(id_variant, isActive, id_store) 

Answer 2

。これはマシンが負荷をかけている間に初めて問題を解決しませんでしたが、2回目は静かなマシンで動作しました。それはちょうどmysqlのように感じ

はフレーク状です。私は本当に何を言いたいのか分からない。