問題タブ [query-tuning]

SQLServer2008を使用しています。

testViewというビューがあります

ビューでは、列の1つがこのページから取得した別のクエリを使用しています-http://www.simple-talk.com/sql/t-sql-programming/concatenating-row-values-in-transact-sql/

つまり、このフォーマットに沿って

次のクエリを実行すると、ビューに60,000行ある場合に約110秒かかります。

このクエリを改善するためにどのような提案を提供できますか？

Oracle 11g SQL*Plus で次のクエリを実行すると、セッションがハングします。

クエリのコストは、その時点でデータベースで利用可能なデータの量に依存するかどうか教えてください。

つまり、データ量の変動によってコストが変動するのですか?

ありがとう、サビサ

ユーザーが金額を含む金融取引を入力できるシステムがあります。トランザクションがシステムに追加/更新または削除されると、アカウントの合計が再計算され、ユーザーに即座に表示される必要があります。ユーザーはシステム内の特定のアカウントにアクセスできますが、すべてではありません。

以下は、アカウントとトランザクションのデータを保持するテーブルのスクリーンショットへのリンクです。

http://i.imgur.com/EqV7w.png

現在、アカウントの合計を取得するには、次のクエリを使用します。

AccountId列とAmount列のTransactionテーブルに、一意ではない非クラスター化インデックスがあります。これにより、クエリでAccountIdによってトランザクションをすばやく見つけることができます。

それは私が望むことをしますが、私の懸念は、トランザクションテーブルがかなり急速に成長していることです。現在、そこには約100万のレコードがあり、時間の経過とともに数千万に達すると予想しています。また、トランザクションを積極的に編集できるユーザーも増えており、システムには約5500人のユーザーがいます。

システムがスケールアウトできるように、アカウントの合計$を取得するときに、トランザクションテーブルの使用を制限するソリューションを検討しています。そのための2つの解決策があります：

1. ユーザーがその情報を必要とするときに特定のボタンをクリックするように求めることにより、オンデマンドでアカウントの合計を計算します。私はそのルートに行くかもしれませんが、アカウント合計のリアルタイム更新で自分のオプションを探求したいと思います。
2. 現在の合計を別の場所に保存し、それを使用してアカウントの合計を計算します。これらすべてのニュアンスを知っている単一のインターフェースを介してすべてを実行する必要があるため、それに関連する制限があります。現在の合計も更新されていることを確認する必要があるため、データベース内のトランザクションの編集には注意が必要です。

データベースのパフォーマンスを気にせずに、アカウントの合計をリアルタイムで計算する他の方法を探しています。

このクエリの最適化について助けが必要です:

EXPLAIN 出力:

MySQLの説明を読み、理解し、最適化する方法を理解するのにまだ問題があります。orderby列にインデックスを作成することは知っていますが、それだけです。したがって、このクエリの調整にご協力いただければ幸いです。

このクエリが行うことは、種のカルマが最も多い写真を見つけることです。このライブの結果を見ることができます：

http://www.jungledragon.com/species

画像ごとに複数の画像ファイル（フォーマット）があるため、種のテーブル、画像のテーブル、その間のマッピングテーブル、および画像ファイルテーブルがあります。

出力の説明：

種のテーブルについては、プライマリIDとフィールドcommonnameにインデックスがあります。画像テーブルについては、idフィールドとkarmaフィールドにインデックスがあり、他にもこの質問に関係のないものがいくつかあります。

このクエリは現在0.8から1.1秒かかりますが、私の意見では遅すぎます。正しいインデックスがこれを何度もスピードアップするのではないかと疑っていますが、どれがどれかわかりません。

Oracle Explain Planでコストがどのように評価されるかを説明できる人はいますか? クエリのコストを決定する特定のアルゴリズムはありますか?

たとえば、フル テーブル スキャンのコストは高く、インデックス スキャンのコストは低くなり full table scanますindex range scan。

このリンクは、私が求めているものと同じです: Oracle Explain Planのコストに関する質問

しかし、誰かが例を挙げて説明できますか? を実行することでコストを見つけることができますが、explain plan内部的にはどのように機能するのでしょうか?

UNION ALL は UNION よりも優れたパフォーマンスを発揮するはずであることを私は知っています (参照: union と union all のパフォーマンス)。

今、私はこの巨大なストアド プロシージャ (多くのクエリを含む) を持っています。最終的な結果は、それらの間に UNION を持つ 2 つのセクションの SELECT です。両方のデータセットは互いに外部であるため、より優れていると思われる UNION ALL を使用できます (個別の操作はありません)。

私はいくつかのデータベースでそれをチェックしましたが、うまくいきました。問題は、顧客の 1 人がパフォーマンス チューニング用にデータベースを提供してくれたことです。調査したところ、UNION ALL を UNION に変更すると、パフォーマンスが少し向上することに気付きました (!)。これが、ストアド プロシージャで行ったすべての変更です。

誰かがこの状況がどのように発生するかを説明できますか???

ありがとう、
ジヴ

更新：
両方のクエリの実行計画を添付（差分部分）：

私のプロジェクトでは、以下の T-SQL コードで課題に遭遇しました。

1. step1 は、UserModules テーブルに親モジュールとそのサブスクライブしているユーザーを入力します。
2. step2 は、Modules_Hierarchy テーブルで step1 のモジュールに関連付けられた子モジュールをチェックし、子モジュールを親モジュールのサブスクライブ ユーザーにマッピングすることによって、UserModules テーブルに有効なレコードを挿入します。このステップは、すべての子モジュールが見つかるまで再帰的に繰り返されます。

問題：

ステップ 2 では、WHILE ループと SELECT ステートメントが相関サブクエリを使用し、テーブル UserModules が INSERT 句と関連する SELECT 句の両方の一部であるため、パフォーマンスが低下し、LOCK エスカレーションの問題でクエリが失敗することがよくあります。

ModulesUsers テーブルの最終的なデータ サイズは 4,200 万で、今後さらに大きくなることが予想されます。

エラー メッセージ:「SQL Server データベース エンジンのインスタンスは、現在 LOCK リソースを取得できません。アクティブなユーザーが少なくなったら、ステートメントを再実行してください。データベース管理者に依頼して、このインスタンスのロックとメモリの構成を確認するか、実行時間の長いトランザクションを確認してください。」</p>

このクエリを最適化する方法、つまり問題を解決するためのステップ 2 を教えてください。

ステップ1：

ステップ2：

更新: 以下でこれに答えました。

MySQL クエリのパフォーマンスの問題を修正しようとしています。私が見ていると思うのは、関数の結果を変数に割り当ててから、その変数と比較して SELECT を実行するのは比較的遅いということです。

ただし、テストのために、変数との比較を、(特定のシナリオで) 関数が返すことがわかっているものと同等の文字列リテラルとの比較に置き換えると、クエリははるかに高速に実行されます。

例えば：

オプション A の行を使用すると、クエリが遅くなります。

オプション B の行を使用すると、単純な文字列の比較が期待されるように、クエリが高速になります。

なんで？