私は常に、最初に最小限のインデックス セットを使用してデータベースを展開し、次にパフォーマンスに応じてインデックスを追加/変更するというアプローチをとってきました。
このアプローチはかなりうまく機能します。ただし、どこでパフォーマンスを改善できるかはまだわかりません。ユーザーが文句を言うほどパフォーマンスが悪い場所を教えてくれるだけです。
現在、多くのアプリケーションでデータベース オブジェクトをリファクタリングしている最中です。
「時期尚早の最適化はすべての悪の根源である」ので、わざわざパフォーマンスの改善を探すべきではないでしょうか?
アプリケーション コードをリファクタリングするとき、開発者はコードの品質を改善する方法を常に探しています。データベースのパフォーマンスも常に向上させる方法はありますか? もしそうなら、どのツールやテクニックが最も役に立ったと思いますか?
「データベース エンジン チューニング アドバイザー」を簡単に試してみましたが、まったく役に立ちませんでした。たぶん、結果を解釈するための経験がもっと必要なだけです。
私のアプローチは、SQL Server Profilerを使用して、サーバーまたはデータベースに対するコマンドをテーブルに収集することです。それができたら、最大および平均実行時間、最大および平均CPU時間、および（非常に重要な）クエリが実行された回数に基づいてクエリを実行できます。
すべてのデータベースアクセスコードをストアドプロシージャに入れようとしているので、クエリを簡単に分割できます。インラインSQLを使用する場合、クエリの値を変更すると別のクエリのように見えるため、難しい場合があります。LIKE演算子を使用してこれを回避し、同じタイプのクエリを同じバケットに入れて集計（max、avg、count）を計算することができます。
潜在的な問題の「トップ10」リストを取得したら、それらを個別に調べて、クエリをやり直すことができるか、インデックスが役立つか、またはアーキテクチャを少し変更する必要があるかどうかを確認できます。トップ10を見つけるには、さまざまな方法でデータを調べてみてください。平均*期間中の総コストのカウント、最悪の違反者の最大、単なる平均など。
最後に、必要に応じて、さまざまな期間にわたって監視するようにしてください。データベースの使用法は、ユーザーが新しいデータを入力している正午とは、全員が日次レポートを取得して実行している朝とは異なる場合があります。また、夜間のプロセスは他のどのクエリよりも時間がかかる場合でも、営業時間外に実行されるため、問題ではないと判断する場合もあります。
幸運を！
「時期尚早の最適化は諸悪の根源」
データベース プログラミングに関しては、この引用はナンセンスだと思います。開発者は最初から効率的なコードを書きたいとは思わないため、アプリケーション全体を書き直すのは非常にコストがかかります。すべての t-sql コードは、次にデータベースのパフォーマンスにどのように影響するかという観点から考える必要があります (もちろん、データの整合性が第一です)。パフォーマンスは、データの整合性以外のすべてに優先する必要があります。
はい、問題が発生するまで実行してはいけない最適化がありますが、当然のこととして実行する必要があり、後で修正しないでください。効率の悪いコードが効率にどのように影響するかを理解すれば、そうでないコードよりも、効率の良い可能性のあるコードを書くのに時間はかかりません。カーソルコードに関する Cervo の議論はその一例です。セットベースのアクションは、ほとんどの場合、カーソル ソリューションよりもはるかに高速です。ほとんどの場合、カーソルを作成するよりもセットベースのソリューションを作成する方が時間がかかりませんが、その方法を実現する唯一の方法は、カーソルを作成しないことです。
また、フィールド名を指定する代わりに select * を使用する理由はありません。MSSQL では、これらの名前をオブジェクト エクスプローラーからドラッグできるので、それを行うのが難しすぎることはわかりません。しかし、実際に必要なフィールドのみを指定することで、ネットワーク リソースとデータベース サーバー リソースと Web サーバー リソースを節約できます。では、なぜプログラマーは select * の遅延オプションを使用して、後で最適化することを心配する必要があるのでしょうか?
インデックスと同じこと。あなたは、インデックスの最小限のセットを行うと言います。最小の定義方法によっては、それで問題ないかもしれませんが、すべての外部キーにインデックスを付けることが重要であり、最も頻繁に where にあるいくつかのフィールドにインデックスを持たないデータベースをプッシュしたくありません条項。ユーザーがクライアントの外部にいて、内部にいない場合、サイトの速度が遅いことに文句を言うことはなく、別の場所に移動します。最初から効率的なデータベース アクセスを計画することは、ビジネス上意味のあることです。
最初から効率を考慮しないことについての私の主な懸念の 1 つは、物事が遅すぎる最初の数回、企業はパフォーマンスの調整ではなく、問題により多くの機器を投入する傾向があるということです。人々がパフォーマンス アクネ チューニングを開始するまでに、数ギガバイト以上のデータベースがあり、結果よりも多くのタイムアウトを取得している多くの不幸な顧客がいます。この時点で、多くの場合、データベース内のほぼすべてを書き直す必要があり、その間に顧客を失います。ある企業で商用アプリケーションのサポートを提供していたのを覚えています。顧客サービス担当者が電話ですでに不満を抱いている顧客を助けようとしているときに、ある画面から別の画面に移動するのに文字通り 10 分かかりました。
SQLServer実行プラン!!! ここに移動します：http：//dbalink.wordpress.com/2008/08/08/dissecting-sql-server-execution-plans-free-ebook/
プロファイルを作成したら、問題があると思われるクエリをSQLクエリアナライザに入力し、実行プランを表示します。コストのかかるテーブルスキャンを実行しているクエリの部分を特定し、これらのテーブルのインデックスを再作成して、このコストを最小限に抑えます。
これらのリファレンスを試してください：
プロファイリングは重要ですが、プロファイリング セットを使用する場合は、それがデータの正確なテスト セットであることを確認する必要があります。そうしないと、チューニング ツールで必要な正確な結果が得られません。
また、2005 年のフラグメンテーションと使用状況レポートを含む管理オブジェクトは非常に役立ちます。
もちろん、クエリのプロファイルを作成し、実行計画を確認する必要があります。しかし、何度も何度も出てくる主な 2 つのことは、できるだけ早くできるだけ多くを除外することと、カーソルを回避しようとすることです。
私は、誰かがイベントのデータベース テーブル全体をクライアントにダウンロードし、いくつかの基準に基づいて各行を 1 つずつフィルタリングするアプリケーションを見ました。フィルター条件をデータベースに渡し、クエリで where 句の条件を適用すると、パフォーマンスが大幅に向上しました。これは、データベースを扱っている人には明らかですが、似たようなことが起きているのを見てきました。また、必要のない行でいっぱいの一時テーブルの束を格納するクエリを持っている人もいますが、それらは一時テーブルの最終的な結合で削除されます。基本的に、一時テーブルにデータを入力するクエリを除外すると、残りのクエリのデータが少なくなり、クエリ全体がより高速に実行されます。
カーソルは明らかです。100万行あり、行ごとに移動すると、永遠にかかります。いくつかのテストを行うと、Perl のような「遅い」動的言語を使用してデータベースに接続し、データセットに対して行ごとの操作を実行した場合でも、速度はデータベース内のカーソルよりもはるかに高速です。Java/C/C++ などで実行すると、速度の差はさらに大きくなります。データベースコードでカーソルを見つけたり削除したりできる場合は、はるかに高速に実行されます...カーソルを使用する必要がある場合は、その部分をプログラミング言語で書き直してデータベースから取り出すと、おそらくパフォーマンスが大幅に向上します。
カーソルに関するもう 1 つの注意点として、SELECT @col1 = col1、@col2 = col2、@col3 = col3 where id = @currentid のようなコードは、ID を通過し、各列でステートメントを実行するループ内にあることに注意してください。基本的にこれもカーソルです。それだけでなく、実際のカーソルを使用すると、多くの場合、これより高速になります。特に static と forward_only です。操作を設定ベースに変更できれば、はるかに高速になります.....そうは言っても、カーソルにはいくつかの場所があります....しかし、パフォーマンスの観点から、設定ベースでカーソルを使用するとペナルティがありますアプローチします。
実行計画にも注意してください。数秒かかる操作は非常にコストがかかり、数分かかる操作は非常に安価であると推定される場合があります。実行計画を表示するときは、SELECT 'At this area', GETDATE() をコードに挿入して、すべてを確認してください。
明らかなものではなく、さまざまなテーブル、ビューなどにアクセスする複雑なクエリ、および/またはさまざまなテーブルから多くの行を返すクエリをプロファイリングします
それはあなたがどこに焦点を合わせるべきかを正確に教えてくれます
私のアドバイスは、このコンテキストでの「時期尚早の最適化はすべての悪の根源である」というのは絶対にナンセンスだということです。
私の見解では、設計がすべてです。データ スキーマを設計するときは、同時実行性、ホットスポット、インデックス作成、スケーリング、および使用パターンについて考える必要があります。
必要なインデックスと、プロファイリングを行わずにすぐに構成する方法がわからない場合は、すでに失敗しています。
クエリの実行を最適化する方法は何百万もありますが、どれもうまくいっていますが、結局のところ、データは指定した場所に到達します。
現在のインデックスの内部および外部のフレーム化を確認し、それらを削除して再作成するか、再編成することをお勧めします。
行数と負荷に関して、本番ボリュームを使用してプロファイリングしていることを確認してください。クエリとその計画は、さまざまな負荷/ボリューム シナリオの下で異なる動作をします
MS SQL について話しているようです。
プロファイラーを開始し、データベースで実行する最も一般的なクエリを記録します。次に、実行プランをオンにしてこれらのクエリを実行すると、何が (もしあれば) クエリを遅くしているのかがわかります。次に、クエリを最適化したり、フィールドにインデックスを追加したりできます。
SQL Books では、プロファイリングとクエリ分析の両方の機能の概要を説明しています。
私のアドバイスは、すべてのデータベースに適用できる手法から始め、次に MSQL に固有の手法を試すことです。
SQL の最適化は難しく、厳格なルールはありません。次のような、従うことができる一般的なガイドラインはほとんどありません。
ただし、重要な点は、常に 80 対 20 のルールを適用する必要があるということです。つまり、どのシステムでも、パフォーマンスを最大限に向上させるには、コードの 20% (多くの場合それよりも少ない) を微調整する必要があります。ベンダーが提供するツールは通常、実行のアプリケーション/ビジネス コンテキストを推測できないため、ここで失敗します。