SQL Serverのパフォーマンスが低下する原因は何ですか？

Question

私のデータベースからのデータ検索のパフォーマンスが遅いことがわかったたびに。私はのSQLクエリのどの部分が問題を抱えているのか把握し、それを最適化しようとしており、のインデックスをテーブルに追加しようとしています。しかし、これは常に問題を解決するわけではありません。

私の質問は：SQLサーバーのパフォーマンスを改善するために、他のトリックは

ありますか？

SQLサーバーのパフォーマンスを悪化させる原因は何ですか？

Answer 1

• 非効率的なクエリのデザイン
• あまりにも多くのインデックステーブルの上に
• 少なすぎインデ​​ックスが
• が正しくクラスタ化インデックスを選択していないテーブルの上に維持すること
• オート成長しているファイルが
• インデックス保守不良による断片化
• クラスタ化インデックスがないためのヒープフラグメンテーション
• 高すぎるFILLFACTORsは、過度の領域の使用状況を引き起こして、インデックスに使用FILLFACTORの
• 低すぎると、過剰なページ分割を引き起こし、インデックスに使用され、スキャン時間を増加
適切な
• 非選択的なインデックスが使用されてカバーされたインデックスを使用していない
• データベース（日付の統計のうち）統計の
• 不適切なメンテナンスが適切に同じドライブスピンドル共有
• トランザクションログとデータを正規化しない
• 台の間違ったメモリ構成
• が少なすぎるとメモリ
• 少なすぎるCPU
• 遅いハードドライブ
• ハードドライブやその他のハードウェア、あなたのCPU
• 共有を噛むデータベースサーバー上の
• A 3Dスクリーンセーバーを失敗CPUとメモリを競合する他のプロセスを持つデータベースサーバー
• クエリ間の競合のロック
• 全体をスキャンするクエリ大きなテーブル
（行によってネストされたループ、行）が必要でない、および/またはFAST_FORWARDない
• カーソルをinefficent方法でデータを検索
• フロントエンドコード
• 大規模なテーブルがカーソル付きされたときにNOCOUNTを設定しませんスルー。
• 高すぎるトランザクション分離レベルをクライアントとSQL Serverの間
• あまりにも多くのラウンドトリップ（おしゃべりインタフェース）
• 不要なリンクサーバークエリ
を（そのようなことは必要ないときSERIALIZABLE使用など）を使用して、
• があまりにも多くのデータを選択
• 過度のクエリの再コンパイル

定義されていない主または候補キーであるリモートサーバ上のテーブルを対象とリンクサーバークエリ

ああ他にもあるかもしれません。

Answer 2

データベースを初めて使用していて、データベース・エンジン・チューニング・アドバイザにアクセスできる場合は、データベースをヒューリスティックにチューニングできます。

基本的にSQLプロファイラでDBに対して実行されるSQLクエリを取得し、それをDETAにフィードします。 DETAは事実上（データを変更することなく）問合せを実行し、問合せをより良くするためにデータベースに欠落している情報（ビュー、索引、パーティション、統計など）を処理します。

これは、あなたのためにそれらを適用し、将来監視することができます。私はDETAが常に正しいことを理解していないことを想定すると言っているわけではありませんが、クエリーが何をしているか、どのくらいの時間を要しているか、どのようにDBを索引付けできるかを確認するには、適切に。

PS：プロジェクトの開始時に優れたDBAに投資して、優れた構造と索引付けを開始する方がはるかに優れています。しかし、それはあなたの現在のポジションではありません...

Answer 3

この問題を抱えている新しい開発者と話すとき、私は通常2つの問題のいずれかが原因であることを発見します。これら2つのルールに従えば、両方とも修正されます。

まず、不要なデータは取得しないでください。たとえば、ページングを行っている場合は、100行を戻してから、そのページに属するものを計算しないでください。格納されたprocはそれを把握して、必要なものだけを取り出します。

第2に、あなたがしない作業より速いものはありません。たとえば、私は、要求されたすべてのページでユーザーの完全な役割と権限が取得されたシステムで作業しました。これは、一部のユーザーにとっては100行でした。最初のリクエストでこれをセッション状態に保存してから、後続のリクエストでそれを使用しても、データベースからは有意義な重みがありました。

Answer 4

使用しているデータベースのパフォーマンスチューニングに関する良い本を得ることをお勧めします（これは非常にデータベース固有のものです）。これは非常に複雑なテーマであり、Web上の一般的なもの以外には本当に答えられません。

たとえば、非効率的なクエリは問題を引き起こす可能性があり、非効率的なクエリやそれを修正する方法がたくさんあります。

Answer 5

これは非常に広い質問です。そしてすでにたくさんの回答があります。それでも私は1つの重要な要因 - Page Splitを追加したいと思います。問題は、良いスプリットと悪いスプリットがあることです。悪い/厄介なページを識別するためのtransaction_log拡張イベントを使用する方法を説明する良い記事は、次のとおり

1. Tracking Problematic Pages Splits in SQL Server 2012 Extended Events - Jonathan Kehayias
2. Tracking page splits using the transaction log - Paul Randal

を分割あなたが言及：

を、私はそれを最適化しようとすると、また、いくつかのインデックスを追加する

ただし、未使用の非クラスタ化インデックスを削除すると、パフォーマンスが向上し、トランザクションログが減少する場合があります。 Read Top Reasons for Log Performance Problems

Wait statistics, or please tell me where it hurtsパフォーマンス分析にwait statisticsを使用する方法を説明します。

に Performance Considerations - sqlmag.com

1. 別々のテーブルを見てみましょう、パフォーマンスのためにいくつかの新鮮なアイデアを表示するには、（ - ファイルグループの並列ディスクのI/O）別のディスクに結合します。
2. 一意の値がほとんどない列の結合を避けてください。

JOINを理解するために、プロファイラを実行し、クエリが遅いところ、それはあなたを教えてみましょうAdvanced JOIN Techniques