取得する列を指定する場合と比較して、SQL テーブルからすべての列を選択するのはコストがかかりますか?
SELECT * FROM table
対
SELECT col1, col2, col3 FROM table
クエリを実行しているテーブルの一部に 100 を超える列があることを知っておくと役立つ場合があります。
質問する
1257 次
4 に答える
4
そうかもしれません。テーブルに定義されているインデックスによって異なります。
クラスター化col1,col2,col3されていないインデックスがある場合、そのインデックスを使用してクエリを満たすことができます (ヒープまたはクラスター化インデックスのいずれかであるテーブル自体よりも狭いため)。これにより、I/O コストが削減されます。
また、一般的に、どのクエリがテーブル内の特定の列を使用しているかを判断できるようにするためにも推奨されます。
テーブルにインデックスがない場合、クラスター化インデックスが 1 つしかない場合、または特定のクエリをカバーするインデックスがない場合は、ヒープ/クラスター化インデックスのすべてのページにアクセスする必要があります。それでも、行外のデータ (大きなデータなどvarchar(max)) がある場合、その列をに含めなければ、そのI/O コストをSELECT回避できます。
于 2013-05-03T08:38:56.617 に答える
1
主な問題に分解してみましょう。
実際のデータベース/アプリケーション: クエリの入力方法は、SQL アプリケーションが実際にクエリを最適化する方法、データの取得元などを変更する可能性があります。ここで一般化するのは難しく、データベース アプリケーションとセットアップに依存します。
プログラマー向けのリソース: 入力する代わりに * を使用する方が、簡単で迅速です。わーい！そして、コマンドの背後にある「意味」が文字通り「すべてを取得する」である場合、手動ですべての列をリストする代わりに * を使用するのは、おそらくプログラマーのコミュニケーションの良いビットです。後でコードを読むプログラマーとして何百もの列名のリストに直面するのは不快な経験です。一方、手動でリストを作成することは、それらの列を具体的に要求している何らかの理由があるというちょっとしたシグナルとして機能する可能性があります。強い信号ではありませんが、それでも信号です。
その他のリソース/IO/メモリなど: 実際には 100 列すべてを必要とせず、怠惰なためにクエリを実行している場合は、さらに灰色の領域に入ります。データベースは何からロードされていますか? クエリの結果はどこに行くのですか? それらの読み取り/書き込み速度はどのくらいですか? 本当にすべての列でそれをしたいですか? クエリの実行に使用されるメモリまたはリソースの量は? インデックスを使用しますか？インデックスされていますか？この段階で最適化を気にする必要さえありますか?
つまり、一長一短は、グレーゾーンです...
于 2013-05-03T08:52:48.513 に答える