問題タブ [full-table-scan]

非常に興味深い SQL クエリをテストしました。残念ながら、このクエリの実行は少し遅いことが判明しました - O(n2) - そして、最適化されたソリューションを探していますか、それともまったく異なるソリューションを探していますか?

ゴール：

http://www.sqlfiddle.com/#!9/07e5d/4

クエリは正常に動作し、正しい結果が表示されますが、スキャンする行が多すぎる場合はもちろん、少なくとも 2 つのフル テーブル スキャンが使用されます。

(a) 最初に特定の日付範囲内のすべての record_customer_id を選択し、そのクエリの結果を保存してから、(b) これらの保存された結果に対して SQL フィドルで作業クエリを実行することは可能ですか?

それとも、優れたパフォーマンスを発揮するまったく異なるアプローチがあるのでしょうか?

どんな助けでも大歓迎です！

タームリストとブラックリストの 2 つの MySQL テーブルを取得しました。どちらもフィールド「用語」にインデックスがあり、ブラックリストにはフィールド「ステータス」に別のインデックスがあります。

ステータスが「A」のブラックリストにも表示される用語リストの用語のステータスを「B」に更新したい場合は、次の SQL ステートメントを発行します。

これにより、termlist で完全なテーブル スキャンが実行されます。「内部結合による更新」を使用したいのですが、select ステートメントに where 句があるため使用できません。

そのselectステートメントから一時テーブルを作成し、その一時テーブルで内部結合を更新できることは知っていますが、この更新を何度も行う場合、これはちょっと面倒です。

テーブル全体をスキャンせずに作業を実行できる単一の更新ステートメントはありますか?

when句の一部がis nullになる単純な結合ステートメントがあります。ステートメントはアプリケーションによって生成されます。this is null制約があると、クエリ プランに問題が発生します。StackExchange の記事で説明されているアプローチに従い、列の複合インデックス (null 許容型と結合するインデックス) を作成しました。インデックス付きの列のみを選択する場合にのみ役立ちます。インデックスのない列を選択すると、それは無視されますが、クエリの結果は同じです (行が選択されていないなど)。 私たちが見る唯一のオプションは、アプリケーションのロジックを変更することですが、これをデータベースレベルで解決する方法がまだあるのでしょうか?

次に、計画を確認します。

1.

Plan1 - 範囲スキャン

2.

Plan2 (上記と同じリンク) - 全表スキャン

クエリを変更する、よりスマートなインデックスを使用する、固定計画を適用するなど、パフォーマンスを向上させる最善の方法はどれでしょうか?

*更新* この質問を準備している間に、サンプルの計画が自動的に変更されました。現在、 Plan2 の代わりにPlan2*があります - 完全なテーブル スキャンはありません。ただし、サンプルを再作成すると (テーブルを削除して再度準備する)、プランは再び Plan2 (フル テーブル スキャン) になります。このトリックは、実際の DB では発生しません。

条件が満たされたときに最初の (ランダムな) 行のみを抽出するクエリを作成しようとしています。

このクエリの問題は、テーブル全体のスキャンです。テーブルに完全にアクセスすることなく、同じ結果を達成したいと考えています。何か案は？

ありがとう

これは簡単な質問です。大規模なテーブル (500 万行) があり、テーブル全体をスキャンする以外に選択肢がないとします。

データベースが結果をより速く返すようにする方法はありますか?

バックグラウンド：

堅牢で柔軟になるように設計されたサードパーティから提供されたアプリケーションがあります。そのデータベースには非常に少数の大きなテーブルがあります。たとえば、テーブルの 1 つは、すべてのオブジェクトを格納する「オブジェクト」テーブルです。もう 1 つのテーブルは、オブジェクト間のすべての関係を取得する「関係」テーブルです。基本的に、スキーマを変更せずに何でも保存できます。

私の仕事は、別のレポート アプリケーション (このデータベースにクエリを実行するアプリケーション) を設計することです。ライブデータである必要があります。また、テーブルのサイズとクエリの複雑さのために、パフォーマンスの問題があります。

パフォーマンスの問題をどのように処理すればよいのか疑問に思っていました。インデックスの後にインデックスを作成しましたが、クエリは依然として非常に複雑であり、1 日の終わりには、複数のフル テーブル スキャンを行う必要があります。

良いニュースは、私はまだ設計段階にあるということです。何かを見逃した場合に備えて、できるだけ多くの提案を聞きたいと思っています。

大量のデータ (1,000,000,000 行など) を含むテーブルがあります。

テーブル構造:

フェッチするデータを制限するためにそれらのフィールドを使用できないため、テーブルから他のフィールドを省略しました。

ここで主キーはId. 名前の列だけで、インデックスはありません。

n 回 (n=10 とします) を超えて出現する名前のリストを見つける必要があります。

以下のオプションを試しました：

どちらも大きな一時スペースを占めています。

クエリを最適化して使用する一時スペースを減らすためのその他の提案。ここでの速度は、私にとって主な関心事ではありません。クエリに 2 時間程度かかる場合でも問題ありません。

テーブルのインデックス作成を手伝ってもらえますか?

問題は、テーブルにインデックスを付けたことですが、Explain に「フル テーブル スキャン」がまだ残っていることです。

これは私の（作業中の）クエリですが、大きなテーブルでは遅くなる可能性があり、これを変更する方法がわかりません

ps。index3 - 訪問者 = 1 が id = 5 のページを更新するときに値 (1,5) を何回もしたくない

次の自己結合クエリがあります。

クエリは非常に遅く、実行計画を見ると、原因は JOIN でのフル テーブル スキャンにあるようです。テーブルには 500 行しかありません。これが問題ではないかと疑って、オプティマイザーの選択に違いが生じるかどうかを確認するために、100,000 行に増やしました。そうではありませんでした.100k行では、まだ完全なテーブルスキャンを実行していました.

私の次のステップは、次のクエリでインデックスを強制しようとすることでしたが、同じ状況が発生し、フル テーブル スキャンが発生します。

すべての列 (id、lft、rgt) は整数で、すべてインデックスが付けられます。

MySql がここでフル テーブル スキャンを実行するのはなぜですか?

全テーブル スキャンの代わりにインデックスを使用するようにクエリを変更するにはどうすればよいですか?

ありがとう

DynamoDB の仕組みに詳しい方からの助けをお待ちしております。大きな DynamoDB テーブルでスキャンを実行する必要があります。DynamoDBClient のスキャン操作は、返されるデータのサイズが 1 MB に制限されていることを知っています。同じ制限が Table.scan 操作に適用されますか? 問題は、Table.scan オペレーションがタイプ " ItemCollection<ScanOutcome>" の出力を返すのに対して、DynamoDBClient スキャンが ScanResult 出力を返すことです。これらのオペレーションが同様の方法で機能するかどうかは明確ではありません。

http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ScanJavaDocumentAPI.htmlの例を確認しましたが、最後に返されたキーの使用に関するヒントは含まれていません。

私の質問は次のとおりです: Table.scan を使用する場合、lastreturnedkey が null になるまで、サイクルでスキャン呼び出しを行う必要がありますか? はいの場合、最後のキーを取得するにはどうすればよいですか? そうでない場合、ページネーションを強制するにはどうすればよいですか? コード例へのリンクをいただければ幸いです。例を探すためにグーグルで時間を費やしましたが、それらのほとんどは DynamoDBClient または DynamoDBMapper を使用しており、代わりに Table オブジェクトと Index オブジェクトを使用する必要があります。

ありがとう！