skillup

技術ブログ

Database

SQL結合 サブクエリに関して

投稿日:

今回はサブクエリに関してです。

もちろんSQL実践入門を読み進めています。

SQL上ではテーブル、ビュー、サブクエリというのは機能的にはそれほど変わらず主にパフォーマンスの点で違いがでてきます。

以下に簡単な特徴を述べます。

テーブル、ビュー、サブクエリの特徴

テーブル

永続的かつデータを保持する

ビュー

永続的だがデータは保持しないため、アクセスのたびにSQLが実行される

サブクエリ

非永続的なので生存期間(スコープ)がSQL文の実行中に限られる

サブクエリの問題点

ここでサブクエリの問題点を挙げておきます。

計算コストが上乗せされる

データを保持していないので、実行のたびにSELECTを実行してデータを作る必要があります。純粋にSELECT文実行にかかるコストが上乗せされます。

IOコストがかかる

計算した結果は、どこかに保持するため書き込む必要があります。うまくメモリに収まればよいですが、そうでない場合はストレージに書き込むことになり、遅延の原因になります。

最適化を受けられない

サブクエリにはインデックスが利かないため、最適化を受けることができません。

詳細はSQL実践入門の中にゆずりますが、サブクエリの中にはウィンドウ関数を使って代用できるものなどがかなり多くあります。この場合、ウィンドウ関数を使ったほうがパフォーマンスが良くなるケースがあるので積極的に利用しましょう。

-Database

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

HAVING句の活用 発展編

今回からはまたまたHAVING句です。 下記のようなテーブル(teams)があり、全員が待機状態のチーム(全員がそろっている)を求めます。 member | team_id | status &#82 …

no image

MySQLのマイグレーション(workbench使用)

以前cakePHPにてマイグレーションの手法を紹介したのですが、当然PHP以外をつかっていたり、PHPでもcakeを使っていなければこの方法は通用しません。 何か、汎用的にデータベースの構造の差分がチ …

no image

mavenのリモートリポジトリについて

JPAでO/Rマッパーに慣れてからというもの通常のSQLをごりごり書くのが億劫になってきました。 億劫というかいろいろとリスクがありますね。 問題点としてはコンパイルするときにエラーが検知できなかった …

no image

HAVING句について

本日はHAVINGについて。 かろうじて用法はしっており、たまに使うこともありますが、あまりしっかり理解しているとはいえない状況ですので、掘り下げてみようと思います。 WHEREとは違い、抽出した結果 …

no image

集合としてのSQL

今まで何度かSQLが集合ということを扱ってきました。 今回はそれがよくわかる例を。 実務ではあまりないと思うのですが、集合をイメージしやすい例題として、2つのテーブルが全く同じケースを考えます。 下記 …