問題タブ [mysql-dependent-subquery]

CASE ステートメント内でいくつかのサブクエリを使用する非常に複雑なクエリがあります。

この質問では、完全なクエリは必要なく、人々がすぐに問題に取り掛かるのを妨げるだけです。

したがって、この投稿では疑似コードを使用して作業します。必要に応じてクエリを投稿できますが、それは怪物であり、この質問には役に立ちません。

私が欲しいのは、CASE ステートメント内のキャッシュ可能なサブクエリです。

上記のように、これは単純化された疑似コードにすぎません。

MySql EXPLAIN は、CASE 内で使用されるすべてのサブクエリが依存していることを示しています。これは、(私が正しければ) 毎回実行する必要があり、キャッシュされないことを意味します。

このクエリの高速化に役立つソリューションは大歓迎です。

編集部分: 真のクエリは次のようになります。

質問: これは本当に良い方法ですか? 派生テーブルに含めることができる行数を見ると、よくわかりません。

そして、@ Ollie-Jones で言及されているように、誰かがクエリを変更するのを手伝ってくれるかもしれません:

これが怠惰に聞こえる場合は申し訳ありませんが、私は実際には mysqlguy ではなく、このクエリを作成するだけで何年も頭痛の種になりました。:D

上記のことを (説明なしで) 実行しようとすると、MySQL は DEPENDENT SUBQUERY を使用してビジー状態になり、非常に遅くなります。問題は、オプティマイザがクライアントの各 ID のサブクエリを計算する理由です。スキャンを避けるために、その結​​果をプレーンな「文字列」として配置するのと同じであると信じて、IN引数をgroup_concatに配置しました。

これは 5.5+ の MySQL サーバーでは問題にならないと思いましたか? MariaDb でのテストも同じことを行います。

これは既知のバグですか? これを結合として書き直すことができることはわかっていますが、それでもこれはひどいものです。

クエリが正しい場合、BubQuery は常に空の結果を返します。

最初のクエリ:

結果：

2 番目のクエリ:

結果：

私は試しています：

Sqlfiddle: http://sqlfiddle.com./#!9/d6515f/3 //これはサンプル テーブルです。

クエリの上では、常に空の行が返されます。ただし、各クエリは、単一で実行された場合に結果を返します。本当にどこが間違っているのかわかりません。答えを更新するか、私に提案してください。

よろしくお願いします。データベースを MySQL 5.5 から 5.7 にアップグレードする際に問題が発生し、完全に困惑しました。アップグレードは mysqldump などを使用して行われたのではなく、いくつかの非常に長い SQL スクリプトを使用して、いくつかのタブで区切られた入力ファイルからの再構築として行われました。特に (ストアド プロシージャ内の) 一見無害なクエリの 1 つが問題を引き起こし、その理由がわかりません。

これはかなり単純に見えますが、このクエリの EXPLAIN は、深刻な行スキャンが行われていることを示しています。

重要なのは行列で、UPDATE の場合は 1198100、SELECT サブクエリの場合は 1200537 のようです。これらの数値はどちらも、両方の参照テーブルの合計行数 (両方とも 1207744) にかなり近い値です。したがって、両方の行スキャンに対して完全な行を実行しているように見えますが、その理由はわかりません。MySQL 5.5 では、まったく同じクエリが正常に機能しました。この解決策が役立つことを期待していましたが、「derived_merge=off」をoptimizer_switchに渡し、サーバーを再起動しても役に立ちませんでした.

私は確かに、このクエリが超高速であるとは思っていません。そうである必要はありません。以前は正確には高速ではありませんでしたが (7200rpm の回転ディスクで数分)、MySQL 5.7 へのアップグレード以降、宇宙の熱による死の前に完了することはないように思われます。長いです。アイデアを持っている人はいますか？クエリの書き換えか、my.ini 設定か、それとも何か？

また、何らかの形でプロトコルに違反した場合、または質問を改善できる場合はお知らせください. 上にも書きましたが、初めての投稿です。

お時間をいただきありがとうございます。

編集：このソリューションは有望に見えると一瞬思いました。どうやら、文字セット/照合順序が異なるテーブルは、互いのインデックスを適切に読み取ることができません。すべてが にあると確信latin1していましたが、確認する価値があると考えました。DEFAULT CHARSET=latin1そのため、すべてのCREATE TABLEステートメントに明示的に追加しCHARACTER SET latin1、ステートメントに追加しましたLOAD DATA INFILE。悲しいことに、変化はありません。

CASE...WHEN...THEN のサブクエリを含むクエリがあるとします (私が取り組んでいる実際のクエリは目に負担がかかるため、単純化されています)。

4 つのサブクエリはすべて依存サブクエリです。

4 つのサブクエリはすべて実行されますか? EXPLAIN を実行すると、すべてのサブクエリがプランに含まれます。

それとも、subquery1 だけを先に実行し、その条件が満たされた場合、subquery2 が実行されますか? そうでない場合は、条件が満たされているかどうかを調べるために subquery3 が実行されます。このように、関連するサブクエリのみを実行するストアド プロシージャとしてクエリを書き直したところ、パフォーマンスが向上しました (時間の短縮)。 ）。以前の条件が満たされているかどうかに関係なく、すべてのサブクエリを実行するため、元のクエリがより多くの時間を要していたかどうかを知りたいです。

一般ログをオンにしようとしましたが、サブクエリは個別にログに記録されません。それらはクエリ全体としてまとめてログに記録されるため、どのサブクエリが実際に実行されたかはわかりません。SUBQUERY の MySQL ドキュメントも調べてみましたが、まだ何も見つかりませんでした。