問題タブ [query-optimization]

time_stamp、usr_id、transaction_id、lives_remainingの列を持つレコードを含むPostgresテーブル（「lives」と呼ばれる）を扱っています。各usr_idの最新のlives_remaining合計を取得するクエリが必要です

1. 複数のユーザーがいます（個別のusr_id）
   
2. time_stampは一意の識別子ではありません。同じtime_stampでユーザーイベント（テーブル内の行ごと）が発生する場合があります。
   
3. trans_idは、非常に短い時間範囲でのみ一意です。時間の経過とともに繰り返されます
   
4. （特定のユーザーの）remaining_livesは、時間の経過とともに増加および減少する可能性があります

例：

指定された各usr_idの最新データを使用して行の他の列にアクセスする必要があるため、次のような結果を返すクエリが必要です。

前述のように、各usr_idはライフを獲得または喪失する可能性があり、これらのタイムスタンプ付きイベントは非常に接近して発生するため、同じタイムスタンプを持つ場合があります。したがって、このクエリは機能しません。

代わりに、time_stamp（最初）とtrans_id（2番目）の両方を使用して正しい行を識別する必要があります。次に、その情報をサブクエリからメインクエリに渡して、適切な行の他の列のデータを提供する必要があります。これは、私が機能するようになったハッキン​​グされたクエリです。

さて、これは機能しますが、私はそれが好きではありません。クエリ内のクエリ、自己結合が必要です。MAXが最大のタイムスタンプとtrans_idを持っていることがわかった行を取得することで、はるかに簡単になると思います。テーブル「lives」には解析する行が数千万行あるので、このクエリをできるだけ高速かつ効率的にしたいと思います。私は特にRDBMとPostgresを初めて使用するので、適切なインデックスを効果的に使用する必要があることを知っています。最適化する方法に少し迷っています。

私はここで同様の議論を見つけました。Oracle分析関数に相当するある種のPostgresを実行できますか？

集計関数（MAXなど）で使用される関連する列情報へのアクセス、インデックスの作成、およびより適切なクエリの作成に関するアドバイスをいただければ幸いです。

PS以下を使用して、私の例のケースを作成できます。

フィールドから AutoIncremented の最大値を見つけたい。（使用できる挿入後にフェッチされていない@@SCOPE_IDENTITYなど）これら2つのクエリのどちらがより高速に実行されるか、パフォーマンスが向上しますか。 Idの主キーおよびautoincrementフィールドですTable1。これは Sql Server 2005 用です。

[編集]
はい、この場合Idはクラスター化インデックスを定義したフィールドです。
インデックスが次の場合ID DESC..
そして、はい、1の場合にパフォーマンスがどのように影響を受けるかを知っておくとよいでしょう
。IDはクラスター化されたインデックス+主キーです。
2. Id はクラスター化インデックスであり、主キーではありません。
3. Id は非クラスター化インデックス ASC + 主キーです。
4. Id は非クラスター化インデックス ASC であり、主キーではありません。
5. Id は非クラスター化インデックス DESC + 主キーです。
6. Id はクラスター化されていないインデックス DESC であり、主キーではありません。
7. ID はAutoIncrement

難しい注文ではないことを願っています！

スレッド化されたコメントをサポートできる Web アプリケーションを開発しています。受け取った投票数に基づいてコメントを並べ替える機能が必要です。(スレッド化されたコメントがredditで機能する方法と同じです)

その方法について SO コミュニティからの意見を聞きたいです。

コメントテーブルはどのように設計すればよいですか? これが私が今使っている構造です：

この構造にどのような変更を加える必要がありますか?

このテーブルから詳細を取得して正しい方法で表示するにはどうすればよいですか? （どの言語での実装も大歓迎です。可能な限り最善の方法で実装する方法を知りたいだけです）

CPU/データベースの負荷を軽減するために、この機能を実装する際に注意する必要があることは何ですか?

前もって感謝します。

このクエリが実行されているボックスは、データセンターで実行されている専用サーバーです。

AMD Opteron 1354 クアッドコア 2.20GHz 2GB の RAM Windows Server 2008 x64 (はい、RAM が 2GB しかないことはわかっています。プロジェクトが稼働したら 8GB にアップグレードします)。

そこで、テーブルに 250,000 のダミー行を作成して、LINQ to SQL が生成するいくつかのクエリを実際にストレス テストし、それらがそれほどひどいものではないことを確認しました。

インデックスを使用してこのクエリを17秒に短縮しましたが、この回答のために最初から最後まで削除しました。インデックスのみが主キーです。

現在、データベースには 1 人のユーザー、1 つのカテゴリ、250,000 のストーリーがあり、このクエリを実行しようとしました。

クエリの実行に 52 秒かかり、CPU 使用率は 2 ～ 3% で推移します。メンバーは 1.1GB、900MB の空き容量がありますが、ディスクの使用率は制御不能のようです。@ 100MB/秒で、その 2/3 が tempdb.mdf に書き込まれ、残りが tempdb.mdf から読み取られます。

さて、興味深い部分は...

これら 3 つのクエリはすべて、ほぼ瞬時に実行されます。

最初のクエリの実行計画。
http://i43.tinypic.com/xp6gi1.png

他の 3 つのクエリの実行計画 (順番)。
http://i43.tinypic.com/30124bp.png
http://i44.tinypic.com/13yjml1.png
http://i43.tinypic.com/33ue7fb.png

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

インデックスを追加した後にプランを実行します (再び 17 秒まで短縮)。
http://i39.tinypic.com/2008ytx.png

皆さんからたくさんの有益なフィードバックをいただきました。ありがとうございます。新しい角度から試してみました。必要なストーリーをクエリしてから、別のクエリでカテゴリとユーザーを取得し、3 つのクエリで 250 ミリ秒しかかかりませんでした...問題はわかりませんが、問題が解決した場合は 250 ミリ秒で当分の間それに固執します。これをテストするために使用したコードは次のとおりです。

次のクエリがあります

このクエリの実行には 5 ～ 17 秒かかりますが、多くの場合、関数 dbo.udf_get_event_sitelist(@siteId, @userId) は行を返さないため、クエリはデータを検出しません。

SQL Server にユーザー定義関数を最初に実行させるにはどうすればよいですか。クエリをストアド プロシージャに書き直して、最初にサブセレクトを実行できることを感謝しますが、可能であれば単一の SQL ステートメントで実行したいと考えています。

データベースサーバーに対して実行されているクエリを監視する、ある種のランタイムメカニズムがあるかどうか疑問に思っています。各「タイプ」の実行中のクエリの数を記録します。これらのクエリのパフォーマンスを見てください。次に、このランタイム データに基づいて、どのインデックスを追加/削除する必要があるかを提案します。

私は現在、MySQL に反対しています。他の DB ベンダー向けの同様のツールをご存知でしたら、私も知りたいです。ありがとう！！

個々の部品ごとに在庫データを追跡するテーブルがあります。これはテーブルの簡略化されたバージョンです (一部の非キー フィールドは除外されています)。

特定のピースに何かが起こるたびに、新しい監査レコードが作成されます。たとえば、私の製品 ABC が初めて在庫に追加されたとき、次のようなレコードが得られます。

ABC シリアル番号 555 のコストが変更された場合、新しいレコードが取得されます。

作品が売れた場合、さらに別の記録が得られます。

ABC の新しい作品が持ち込まれた場合、次の記録が得られます。

任意の時点での特定の製品セットの手持在庫値をできるだけ早く取得できるようにする必要があります。

上記の例を使用して、2009 年 1 月 2 日現在の製品 ABC の在庫値を取得したい場合、一意の製品/シリアル番号の組み合わせごとに、01/03/より前の最新のレコードを 1 つ選択する必要があります。 2009 を "OnHand" の状態にしてから、コストを合計します。(現時点では、この select ステートメントがどのようになるかは 100% わかりませんが、少し実験してみます)。

私の質問:これは、私が説明しているタイプの監査テーブルにとって適切な構造ですか? つまり、適切に索引付けされていれば、高速なクエリに適していますか? (このテーブルが数百万行に増えたらどうなるか想像しようとしています。)

過去のレコードを別のテーブルに分割し、「アクティブな」テーブルの ProductID/SerialNumber の組み合わせごとに最新のレコードのみを残す必要がありますか?

フィードバック/提案/コメント/リンクは大歓迎です。

ありがとう！