2

これは奇妙な質問かもしれませんが、それを調査する方法がわかりませんでした。次のクエリを実行する場合:

  SELECT Foo.col1, Foo.col2, Foo.col3
  FROM Foo
  INNER JOIN Bar ON Foo.ID = Bar.BID

TableName.Column私はただの代わりに使う傾向がありますcol1, col2, col3

性能差はありますか？列ごとにテーブル名を指定した方が速いですか?

私の推測では、列名を検索して区別するのに時間がかかるため、より高速であると思います。

これについて読むことができるリンクを誰かが知っていれば、私は感謝します. 検索方法がわからないため、この質問に適切なタイトルを付ける方法さえ知りませんでした。

4

2 に答える 2

5

まず第一に：これは問題ではありません。列を検索する時間は、一般的なクエリの合計処理時間に比べてごくわずかであるため、パフォーマンスを向上させるには不適切な場所である可能性があります。

2 つ目:参照されるテーブル (およびビューやサブクエリなどのテーブルのような構造) を検索して適切な列を探す必要がないため、それだけよりも高速ですTablename.Colname 。Colname繰り返しますが、違いは統計的ノイズ内にあります。

3 番目: 使用するのTablename.Colname は良い考えですが、他の理由もあります:Colnameのみを使用し、クエリ内のテーブルの 1 つが同じ名前の新しい列を取得すると、非常によく知られている「あいまいな列」になってしまいます。名前」エラー。このような列の典型的な候補は、多くの場合、「コメント」、「最終変更」、および友人です。col 参照を修飾すると、この保守性の問題は単純に解消されます。クエリは常に機能し、新しいフィールドは無視されます。

于 2013-05-13T23:17:31.610 に答える
4

クエリごとに数マイクロ秒のように、より高速であれば、違いはごくわずかです。クエリで言及されているテーブルに関するすべてのデータをメモリにロードする必要があるため、ディスク アクセスは節約されません。これは、データ処理中ではなく、クエリの解析中に行われます。クエリを何千回も実行したとしても、それらの余分な文字を入力するのに費やした時間を埋め合わせることはできません。:)

ただし、クエリが長くなるため、通信に費やされる時間がわずかに長くなります。ネットワーク経由でクエリを送信している場合、おそらく解析中に保存された時間が無効になります。ただし、短いテーブル エイリアスを使用することでこれを減らすことができます。

SELECT t.col1, t.col2
FROM ReallyLongTableName t

原則として、データベースのパフォーマンスを気にするときは、時間がテーブル内の行数のサイズに依存する側面だけを気にする必要があります。非常に小さなテーブルを扱っていない限り、データの量に関係なく同じものはノイズに分類されます (その場合、データベースを気にする必要はありません。フラット ファイルを使用します)。

于 2013-05-13T23:19:10.907 に答える