問題タブ [sqlperformance]

MSAccessで実行されるアプリケーションがありますが、バックエンドデータベースとしてSQLServerを利用しています。これにより、アクセスできるビューを確認するクエリが生成されます。通常のユーザーの場合、これには最大18秒かかります。db_ownerロールのメンバーであるすべてのユーザーの場合、0.2秒かかります。通常のユーザー向けにこれを調整する方法はありますか？たぶん私がAccessでできることはありますか？私は彼らにdb_ownerを与えたくありません、そしてAccessを使わないようにアプリケーションを書き直すことは問題外です。

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

MS Access 2003、SQL Server2008R2を使用

SQL クエリが最高の状態で実行されているかどうかを確認する方法はありますか? SQL Server 2008 を使用しています。たとえば、クエリが予想されるインデックスにヒットするかどうかを知りたいです。

デフォルトでは、SQL Management Studio で大きなテーブルに対して SELECT を実行すると、結果がグリッド テーブルに表示されます。ご想像のとおり、結果セットが数百万行になると、データは SQL Management Studio に表示されるテーブル ウィジェットに送られます。

• それはクエリの実行時間に影響を与えますか?
• その場合、クエリの結果の表示を無効にして、そのクエリのより現実的な実行時間を取得することは可能ですか?

アップデート ：

表示とは、「表示…実行計画」という意味ではなく、画面上にデータを表示することを指します。

SQL Server Management Studio でクエリを複数回実行し、統計を比較して、いくつかのクエリのパフォーマンスをテストしたいと考えています。私の問題は、クエリ結果が表示されるたびに Management Studio のメモリ使用量が増加するため、この方法が正確ではないことです。私にとって重要なのは、リターンセットが大きいため、メモリ消費を増やさないことです（したがって、一時テーブルに配置できません）

次の質問を見つけました: 結果を表示せずに SQL クエリを実行する方法 ですが、私のニーズには合いません。

では、戻りデータを表示せずに SQL Management Studio でクエリを実行する方法はありますか?

パフォーマンスの問題があります。

数百万のレコードに入るテーブルがあり、毎秒 100 回このテーブルにアクセスする (選択) Web ページを提供しています。クエリは非クラスター化インデックスでカバーされています (SP にもラップされています)。

私の質問は、パフォーマンスを改善したい特定のシナリオに関するものです。このシナリオでは常に 300 行を生成し、ビューにインデックスを付けてビューにクエリを実行するビューを作成するのが賢明でしょうか。カバーされたクエリで既存の 2M plus テーブルをクエリしますか?

最近、データベース内にクラスター化インデックスが定義されていないテーブルがいくつか見つかりました。ただし、非クラスター化インデックスが定義されているため、HEAP 上にあります。

分析の結果、select ステートメントが、非クラスター化インデックスで定義された列に対してフィルターを使用していることがわかりました。

これらのテーブルにクラスター化インデックスがないと、パフォーマンスに影響しますか?

完全に調整できないように見えるので、それをprocに変換して、パラメーターへのクエリ時に使用するWHERE条件の1つを移動し、派生テーブルでパラメーターを使用してみました。

意見

ストアドプロシージャ

EXEC myProc（100）は、SELECT * FROM myView WHERE StoreID = 100よりもはるかに高速です。これは当てはまりますか？

注：このコードは完全に意味をなさないか、実行されない可能性があることを私は知っています-私は他のいくつかのJOINを削除することによってそれを単純化しようとしました。実際のコードの唯一の実質的な違いは、WHEREを派生テーブルに移動することです。これはここで行いました。

ビューは、派生テーブルのクエリを実行するときに私のWHEREを考慮に入れて、procと同じくらい高速にするべきではありませんか？

助けてくれてありがとう！

以下に説明する時間のかかるクエリがあるとします。

と仮定しましょう

多くの行を返します(10 M としましょう)。すべての行を BAR のデータと結合する必要があります。

ここで、次の結果を挿入するとしましょう

テーブルにアドホック インデックスを追加します。

私の質問:

ライブクエリでの「JOIN」のパフォーマンスは、アドホック インデックスが追加された前のライブクエリの結果を含むテーブルへの「JOIN」のパフォーマンスとどのように異なりますか?

それを置く別の方法：

JOIN が遅い場合、JOIN 先のテーブルを実際に格納してインデックスを作成することにメリットはありますか?

通常、COUNT(*) を使用すると、クエリが返す行数を知ることができます。

同様に、たとえば、特定のクエリの出力が何メガバイトかを知る方法はありますか?

何かのようなもの

編集：スクリプト化できるので、 *exec sp_spaceused ... * アプローチが好きです！

次のクエリのパフォーマンスを改善するにはどうすればよいか、誰にでもアドバイスをいただけますか。where問題は節によって引き起こされているようです。

データ (テーブルには膨大な行セットが含まれています - 500K+、それが呼び出されるパラメーターのセットは、クエリごとに 2 ～ 5K のレコードが返されることを想定しており、現在は 8 ～ 10 分かかります):

クエリ

更新 1 - 実行計画