問題タブ [derived-table]

create table ステートメントを使用せずに、各列タイプを指定せずに、select ステートメントから一時 (セッションのみ) テーブルを作成することは可能ですか? 派生テーブルでこれが可能であることは知っていますが、それらは超一時的 (ステートメントのみ) であり、再利用したいと考えています。

create table コマンドを作成して、列リストと型リストを一致させておく必要がなければ、時間を節約できます。

みなさん、こんにちは
。いくつかの派生テーブルで結合を使用するMySQLクエリがあります。派生クエリの1つはうまく機能し、正しい数の行が返されます。
しかし、各行の関連テーブルからいくつかの追加情報を表示しようとしています。これは私が苦労しているところです。私はここで同様の質問とともに他のいくつかの質問を読みましたが、それを私のクエリに適用することができません。

クエリは次のとおりです。

私の問題は2番目の派生テーブルにあります...LEFT JOIN (...) AS invoices

MAX（invoice_stamp）を使用して、その会社の最新の関連する請求書のinvoice_stampを取得しようとしています。これは機能しているように見え、invoice_stamp（Unixタイムスタンプ）の値が最大の関連レコードを返します。

しかし、MAX（）集計関数によって返される、そのレコードの一致するinvoice_idフィールドと参照フィールドも取得しようとしています。ただし、invoice_idフィールドとreferenceフィールドは、MAX（）関数によって返されるレコードと一致しません。

派生テーブルの集計関数によって返されるレコードの完全な詳細を取得する方法を知っている人はいますか？

次のことを行うクエリを改善しようとしています。

すべてのジョブについて、すべてのコストを合計し、請求額を合計して、利益/損失を計算します。コストは、購入注文、users_events (エンジニアが割り当てた時間/現場で費やした時間)、使用された在庫など、いくつかの異なるテーブルから取得されます。
クエリは、作業用のサイトの名前などの他の列も出力する必要があります。列を並べ替えることができます (このすべての後に ORDER BY が追加されます)。

私はこれを読みました：http://dev.mysql.com/doc/refman/5.0/en/group-by-optimization.htmlしかし、そこに何かを適用できるかどうか/方法がわかりません。テスト目的で、左、右、中央のフィールドにあらゆる種類のインデックスを追加しようとしましたが、EXPLAIN 出力は改善されませんでした。

生成される行は 5 x 10^21 (このクエリの最適化を開始する前の 3 x 10^42 から減少しました!)
現在、実行に 7 秒かかります (26 から減少) が、1 秒未満にしたいと考えています。

ところで、GROUP BY x ORDER BY NULL は、サブクエリから不要なファイルソートを排除する優れた方法です。( http://www.mysqlperformanceblog.com/2006/09/04/group_concat-useful-group-by-extension/から)

左結合を使用して、このクエリを作成するにはどうすればよいですか。私が使用しているフレームワークは右結合をサポートしていないため、クエリを書き直す必要があります。誰でも私に可能な解決策を提案できますか？

次のテーブルがあります。

1. 次のように、ID 列、説明列、およびカテゴリの親 ID 列を持つカテゴリ テーブル:

2. 次のような顧客 ID と名前を持つ Customer テーブル:

3. Customer と Category の間の多対多の関係である Category_Has_Customer。

カテゴリの深さは 2 レベルのみです。

私のアプリケーションでは、顧客は 0 個以上のカテゴリを持つことができました。顧客が持っているカテゴリの一部またはすべてを表示したいと考えています。たとえば、すべてのカテゴリを表示することを選択した場合、次のテーブルが必要です。

タイトルとクレジット カードのみなど、特定のカテゴリも表示できるはずです。

p>

私はLEFT JOINでそれをやろうとしました。

しかし、行が重複しているため、役に立ちませんでした。

私は SQL や MySQL の完全な初心者ではありませんが、まだ学ぶべきことがかなりあることに気付きました。何度も試し、読んで、検索した後、私はこれについて頭を悩ませることができません。何かご指摘がありましたら、よろしくお願いします。

実際のデータと表を次のように簡略化しました。

スタッフと仕事の 2 つのテーブルが関連しています。さまざまなプロジェクトのスタッフに関するデータが含まれています。

スタッフ：

仕事：

ゴール：

シカゴのスタッフがいるすべてのプロジェクトを、そのプロジェクトのすべてのスタッフの数とともにグループ化します。

期待される結果：

プロジェクト 30 は、そのメンバーがシカゴ出身ではないため、リストされていません。

以下の私のクエリは明らかに間違っています。プロジェクト スタッフ全体ではなく、シカゴ出身のプロジェクト メンバーのみがカウントされます。

同じ派生テーブルを使用して 3 つの連続したクエリを実行する必要があります... MS SQL Server 2008 を使用しています

派生テーブルの方法で 3 つの SQL クエリを同時に実行する方法はありますか

は一度だけ実行されますか?

私は.netを使用しているので... 3つのテーブルを返し、3つのテーブルを含むデータセットをロードできるかどうか疑問に思っています。

ありがとう

Check Ins と Check Outs という名前の 2 つの派生テーブルがあります。

チェックイン

チェックアウト

両方のログが同じ日付であり、チェックアウト値がチェックインより前であってはならないという条件を考慮して、チェックインとチェックアウトをペアにしたいので、このクエリを思いつきました

の結果セットで

問題は、対応するペアのないログも含めたいということです。これはどのように可能ですか？

編集

予想される結果セットには、次のようなログが含まれている必要があります

このようなクエリがあるとします...

特定のタスクに複数の人を割り当てることができます。このクエリの目的は、タスクごとに 1 つの行を表示することですが、タスクに割り当てられた人を 1 つの列に表示します。

さて... tasks、users、およびに適切なインデックスが設定されているとしtasks_assigned_usersます。tasks派生テーブルに結合する場合、MySQL オプティマイザーは引き続き TaskID インデックスを使用しません。なんと!?!?

それで、私の質問は...どうすればこのクエリでtasks_assigned_users.TaskIDのインデックスを使用できるでしょうか? 一時テーブルは不十分なので、それが唯一の解決策である場合... MySQL オプティマイザーはばかげています。

使用されるインデックス:

• タスク
  • プライマリ - タスク ID
• ユーザー
  • プライマリ - ユーザー ID
• tasks_assigned_users
  • プライマリ - (タスク ID、ユーザー ID)
  • 追加インデックス UNIQUE - (UserID,TaskID)

編集:また、このページには、結合が発生する前に派生テーブルが実行/マテリアライズされると書かれています。キーを再利用して結合を実行してみませんか?

編集 2: MySQL オプティマイザーでは、派生テーブルにインデックス ヒントを配置できません(おそらく、派生テーブルにインデックスがないため)

編集 3:これは、これに関する本当に素晴らしいブログ投稿です: http://venublog.com/2010/03/06/how-to-improve-subqueries-derived-tables-performance/ ケース #2 が解決策であることに注意してください。を探していますが、現時点では MySQL はこれをサポートしていないようです。:(

編集 4:ちょうどこれを見つけた:「MySQL 5.6.3 の時点で、オプティマイザーは FROM 句 (つまり、派生テーブル) のサブクエリをより効率的に処理します:...クエリの実行中に、オプティマイザーは派生テーブルにインデックスを追加する場合があります。そこからの行の取得を高速化します。」有望そうです...

取得したテーブルを含むSQLクエリがあります。

派生クエリは次のようになります。

これは、それ自体で完了するのに約2分かかり、30万行近くを引き戻します。クエリ全体（これを内部に含む）は、ほぼ同じです。派生テーブルがないと、1秒もかからないので、問題を引き起こしているのは派生クエリであることがわかります。

私の質問は、dereivedテーブルクエリの速度を改善する方法はありますか？たぶん、StatusHistoryテーブルにいくつかのインデックスを追加します（私はインデックス付けに少しごちゃごちゃしています...）？または、派生テーブルを使用する以外のアプローチはありますか？

任意の提案をいただければ幸いです。

ありがとう