skillup

技術ブログ

Database

SQL基礎 手続き型言語と集合思考の言語

投稿日:

どんな仕事でもそうだと思いますが、長年惰性で使っていると日常の作業はなんとかできてるけど、実は深く理解していない&効率のいいやり方を知らない、ということが結構あります。

私の場合、ちょっと前にCSSを勉強してそれに気づきましたが、SQLでも同じことがいえますね。

根本的なことがわかっていなくて、「SQL実践入門」やSoftwareDesignの連載で書いてありますが、

「SQLは集合指向の言語である」

ということですね。

例えばある帳票への出力の際に、計算値(合計や加減乗除)を出力する場合、1行ごとにループさせた処理をすると非常に重くなります。

このような場合、逆にある程度複雑であってもSQLである程度集計したような計算をしたほうが圧倒的にパフォーマンスが良くなります。

「SQL実践入門」では前者のようなループを過度に使ったSQLのことをぐるぐる系、後者のような集計をしたSQLをガツン系といっています。

ぐるぐる系とガツン系の特徴を書いておきます。

ぐるぐる系

比較的単純なSQLをループを繰り返して複数発生させる

長所

シンプルで書きやすい
実行時間の算出が比較的容易

ここのプログラムが単純なため、実行数をかけることで時間をだいたい算出できる

実行計画が安定する

変動リスクが少なくパフォーマンスの安定性を確保できる。

トランザクション制御が比較的用意

途中までで処理を走らせて途中で中断した場合、リスタートなどをすることができる

短所

遅い

一般的にデータ量に比例する。処理時間そのものに加え、1回1回の処理でオーバーヘッド(SQLを解釈して評価する)時間が比例してかかる

並列分散がやりにくい

リソースを分割した並列処理による恩恵を受けられない

データベースの進化による恩恵を受けられない

処理が単純すぎるため、改善の余地があまりなく、バージョンアップしてもスピードアップの恩恵を受けられない

一般論でいうとこのタイプなSQLは避けるべき。

ガツン系

集計処理が可能な場合は、ループを回すのではなく一括で処理を書いてしまうSQL

長所・短所はほぼぐるぐる系の裏返し

長所

比較的高速

オーバーヘッドの時間がないため、データ量が増えても、処理時間が正比例にはならない

チューニングネタが数多くある

ぐるぐる系に比べると早くするポイントが非常におおい。

短所

書くのが比較的難しい
見積もり時間の算出がやや難しい

-Database
-

執筆者:


comment

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

関連記事

no image

集合としてのSQL

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

no image

SQL基礎 case&groupbyの活用について

主に集計タイプの計算で大活躍するgroupbyについて。 主な用途は集計とカット。特にcase式と連動した集計はかなり使える 例 nameとageで構成されたテーブルがあるとして、年代ごとの人数を出し …

no image

JPAでの多対多のリレーション

以前、このエントリーでJPAのリレーションについて説明しました。 今回は多対多について説明します。 Contents1 テーブル構成2 ソース2.1 CDのエンティティ2.2 Artistのエンティテ …

no image

MySQLのLIMIT,OFFSETに関して&explainの見方など

自作のWEBアプリを作っていたところSELECT句が異常に遅いケースがありました。 発見までにかなり時間がかかったんですが、不可思議な現象としてはOFFSETが小さいときと大きいときで検索スピードが全 …

no image

MySQLのレプリケーションについて

MySQLのレプリケーションについて調べたことなどを。 Contents1 レプリケーションの基礎知識1.1 定義1.2 構成1.3 メリット1.3.1 参照性能の向上1.3.2 可用性の向上1.4 …