SELECT One、Two、Three は、SELECT One、Two、Three、..... と比較してどのくらいコストがかかりますか?
2 つまたは 3 つのテーブルが結合され、100 行のデータを取得する SQL クエリがある場合、必要な数の列のみを選択する必要があるかどうかは、パフォーマンスに影響しますか? または、すべての列をヤンクするだけのクエリを作成する必要があります..
可能であれば、クエリのどの側面が互いに比較して比較的コストがかかるかを理解するのを手伝ってもらえますか? ジョインですか？プルされたレコードの数が多いのですか？selectステートメントの列数ですか？
1 レコード vs 10 レコード vs 100 レコードは重要ですか?
あなたが書いたクエリでのパフォーマンスの低下と発生の観点から、あなたが言及したこれらの要因をランク付けする非常に一般化されたバージョンとして、私は次のように言います：
パフォーマンスを左右するプロパティは常に、所有するデータの量と連動していると言えます。テーブルにそれぞれ 100 行ある場合は結合が高速になる可能性がありますが、テーブルに数百万行ある場合は、より効率的な方法について考え始める必要があります。デザイン。
いくつかのことがクエリのコストに影響を与えます。
まず、使用する適切なインデックスがありますか。結合で使用されるフィールドはほとんどの場合インデックス化する必要があり、外部キーは既定ではインデックス化されないため、データベースの設計者が作成する必要があります。where クラスで使用されるフィールドには、多くの場合、インデックスも必要です。
次に、where 句は検索可能ですか。つまり、正しいインデックスを持っていても、インデックスを使用できますか? 不適切な where 句は、結合や余分な列よりもはるかにクエリに悪影響を与える可能性があります。次のようなインデックスの使用を防止する構文を使用すると、テーブル スキャン以外は取得できません。
LIKE '%test'
次に、必要以上のデータを返していますか? 必要以上の列を返すべきではありません。select * は、列を検索するための追加の作業があり、構造が時間とともに変化するにつれて非常に壊れやすく、悪いバグが発生する可能性があるため、運用コードで使用しないでください。
参加する必要のないテーブルに参加していますか? テーブルがselectで列を返さず、whereで使用されず、結合が削除されてもレコードを除外しない場合、不要な結合があり、削除できます。多くのビューを使用している場合、特に他のビューからビューを呼び出すのを間違えた場合 (これは多くの理由でバグのパフォーマンス キラーです)、不必要な結合が特に蔓延しています。他のビューを呼び出すこれらのビューをトレースすると、ビューを使用する代わりにゼロからクエリを作成した場合は必要なかったのに、同じテーブルが複数回結合されていることがわかります。
必要以上のデータを返すと、SQL Server の負荷が高くなるだけでなく、結果をメモリに保持している場合、クエリがネットワーク リソースと Web サーバーのメモリをさらに消費することになります。それはあらゆる面で悪い選択です。
最後に、パフォーマンスの低い既知の手法を使用していますか?より良い手法が利用可能です。これには、セットベースの代替手段が優れている場合のカーソルの使用、結合が優れている場合の相関サブクエリの使用、スカラー ユーザー定義関数の使用、他のビューを呼び出すビューの使用 (特にネストした場合) が含まれます。複数のレベル. これらの貧弱な手法のほとんどは、行ごとに処理することを伴います.これは、データベースでは一般的に最悪の選択です. データベースを適切にクエリするには、一度に1行ずつ処理するのではなく、データセットの観点から考える必要があります. .
クエリとデータベースのパフォーマンスに影響を与えるものは他にもたくさんあります。この問題を真に理解するには、この問題に関する本を何冊か読む必要があります。これは、メッセージ ボードで十分に議論するにはあまりにも複雑なテーマです。
または、すべての列をヤンクするだけのクエリを作成する必要があります..
いいえ。ちょうど今日、それについて別の質問がありました。
可能であれば、クエリのどの側面が互いに比較して比較的コストがかかるかを理解するのを手伝ってもらえますか? ジョインですか？プルされたレコードの数が多いのですか？selectステートメントの列数ですか？
無駄な結合やデータ取得は時間がかかるため、避ける必要があります。データストアからの行の取得にはコストがかかります。結合は、コンテキスト、定義されたインデックスの量に応じて多かれ少なかれコストがかかる可能性があります...各クエリのクエリプランを調べて、各ステップの推定コストを確認できます。
より多くの列/行を選択すると、パフォーマンスに多少の影響がありますが、正直なところ、使用するよりも多くのデータを選択する必要があるでしょうか?
可能であれば、クエリのどの側面が互いに比較して比較的コストがかかるかを理解するのを手伝ってもらえますか?
必要なクエリを作成し、パフォーマンスが期待どおりにならない場合は、最適化について心配してください。あなたはカートの前に馬を置いています。
他の人が言っていることはすべて真実です。
しかし、通常、適切なインデックスが既にあるテーブルを操作している場合、パフォーマンスにとって最も重要なのは WHERE ステートメントに何が入るかです。そこでは、インデックスのないフィールドを使用したり、最適化できないステートメントを使用したりすることについて、さらに心配する必要があります。
以下に答えるには：
SELECT One、Two、Three は、SELECT One、Two、Three、..... と比較してどのくらいコストがかかりますか?
これは、選択のパフォーマンスの問題ではなく、データのフェッチにかかる時間の問題です。 Select * from Table同じことをSelect ID from Table実行しますが、データのフェッチには時間がかかります。これは、クエリから返される行数と密接に関連しています。
パフォーマンスの理解に関しては、ここに良いリンクがあります
またはグーグルtsqlパフォーマンス
簡単な答え: 必要以上のフィールドを選択しないでください - ソースコードとストアド プロシージャの両方で "*" を検索してください ;)
クエリのどの部分がどのコストを引き起こすかを常に考慮する必要があります。
適切な DB 設計があれば、通常、いくつかのテーブルを結合してもコストはかかりません。（正しいインデックスがあることを確認してください）。
「select *」の主な問題は、結果に予期しない動作が発生することです。そのようなクエリを作成し、かつ columnindex を使用してフィールドにアクセスすると、DB スキーマに永久にロックされます。
考慮すべきもう 1 つの点は、考慮しなければならないデータの量です。些細なことだと思うかもしれませんが、バージョン 2.0 のアプリケーションは突然 ProfilePicture を User テーブルに追加します。そして、100 人のユーザーを選択するクエリは、突然数メガバイトの帯域幅を使い果たします。
次に考慮する必要があるのは、返す行数です。SQL はソートとグループ化において非常に強力であるため、SQL に仕事を任せて、クライアントに移動しないでください。返すレコードの量を制限します。ほとんどのアプリケーションでは、一度に 100 行を超える行をユーザーに返すことは意味がありません。ユーザーにもっと読み込むことを選択させることもできますが、それはユーザーが選択しなければならないものにします。
最後に、SQL Server を監視します。それに対してプロファイラーを実行し、最悪のクエリを見つけようとします。SQLクエリは0.5秒より長くかかるべきではありません.もしそうなら、何かが台無しになっている可能性が高いです(はい...もっと時間がかかる操作がありますが、それらには理由があるはずです)
編集：遅いクエリを見つけたら、実行計画を見てください...クエリのどの部分が高価で、どの部分がうまく機能するかがわかります...オプティマイザーも使用できるツールです。
結合にはコストがかかる可能性があります。インデックスを使用できない最悪のシナリオでは、O(M*N) 時間かかります。ここで、M と N はテーブル内のレコード数です。CREATE INDEX速度を上げるために、結合条件の一部である列を使用できます。
列の数は、行の検索に必要な時間にはほとんど影響しませんが、より多くのデータを送信する必要があるため、速度が低下します。
SELECT One, Two, Three FROM ...との違いはSELECT One,...,N FROM ...、昼と夜の違いのようなものかもしれません。この問題を理解するには、カバリング インデックスの概念を理解する必要があります。
カバリング インデックスは、インデックス自体が必要なデータ フィールドを含み、データを返すことができる特殊なケースです。
不要な列を射影リストに追加すると、クエリ オプティマイザーは、新しく追加された列を「テーブル」(実際にはクラスター化インデックスまたはヒープ) で検索するようになります。これにより、実行計画が効率的な狭い範囲のインデックス スキャンから変更されたり、肥大化したクラスター化されたインデックス スキャンにシークされたりする可能性があります。これにより、データに応じて、1 秒未満から数時間の時間差が生じる可能性があります。そのため、不要な列の射影は、多くの場合、クエリに最も影響を与える要因です。
プルされたレコードの数は、より微妙な問題です。数が多いと、クエリがインデックスの転換点に達し、より狭いインデックス範囲のスキャンとルックアップよりもクラスター化されたインデックス スキャンを選択する可能性があります。クラスター化されたインデックスへのルックアップが最初に必要であるという事実は、狭いインデックスがカバーしていないことを意味します。これは、最終的には不要な列の射影によって引き起こされる可能性があります。
そして、いよいよ合流。ここでの質問は、他の何とは対照的に、結合です。結合が必要な場合、代替手段はありません。これについては、これですべてです。
最終的に、クエリのパフォーマンスは、IO の量という 1 つの要因だけによって左右されます。また、IO の量は、クエリを満たすために利用できるアクセス パスによって最終的に決まります。つまり、データのインデックス作成によって。不適切なインデックスに対して効率的なクエリを作成することは不可能です。適切なインデックスに対して不適切なクエリを作成することは可能ですが、多くの場合、オプティマイザが補正して適切な計画を立てることができます。インデックスの設計をよりよく理解するために全力を尽くす必要があります。
最初に I/O の観点からクエリを検討することをお勧めします。私の SATA II システムのディスク I/O は 6Gb/秒です。私の DDR3 メモリ帯域幅は 12GB/秒です。ディスクから取得するよりも 16 倍速くメモリ内のアイテムを移動できます。（ウィキペディアとトムのハードウェアを参照）
いくつかの列を取得する場合と 100 行のすべての列を取得する場合の違いは、ディスクから単一の 8K ページを取得する場合と、ディスクから 2 つ以上のページを取得する場合の違いになる可能性があります。ページが最終的にメモリ内にある場合、2 つの列またはすべての列をハッシュ テーブルに移動することは、私が持っているどの測定ツールよりも高速です。
データベース設計に関連するこのトピックについて、他の方々からのアドバイスをお待ちしております。対象となるインデックスを作成するためにインクルード カラムを使用し、適切な WHERE 句を使用してシークを優先してテーブルまたはインデックス スキャンを回避し、狭い主キーなどを使用する狭いインデックスの設計は、DBA の肩書きを持つことと DBA であることの違いです。