ぐるぐるSQLは止めてくださいという話 - Qiita

1. はじめに 仕事の都合で DB/SQL の性能問題を調査する機会が少なくありませんが（決してメインの仕事ではないですが）、その中でよく出くわす問題の１つに「ぐるぐるSQL」（もしくは「ぐるぐる系」）といわれる、ループで大量の SQL 文を呼び出しているものがあります。 感覚ですが、私の周りでは OLTP 系システムの DB/SQL の性能問題の原因の割合は以下のように感じています。 30%：ぐるぐる SQL 20%：SQL 文の書き方が不適切 15%：索引がない or 不適切 15%：パーズが遅い 10%：データモデルがおかしい 10%：その他 （大昔は２番目 / ３番目がほとんどだったのですが、最近はなぜがぐるぐる SQL が多い…） ぐるぐる SQL の実装では、ネットワーク通信や、アプリ側のクエリ生成 / 結果データ構築、DB 側のクエリ受信 / 結果送信といった、処理の本質的で

[wwolf]

ループの中で毎回SQL発行するようなコード書いてる人が「Goを使えばもっと早くなります！！」とか言ってた時はあやうく怒鳴りつけるところだった

[ka-ka_xyz]

ORMの罠というか、クエリを隠蔽した結果としてコードを書く側がコード上のロジックだけで何とかしてしまいがち問題。

[programmablekinoko]

SQLをORMを使ってループ内でちびちびデータを取り出すなという話、そらそうや

[nippondanji]

敢えて言うがJOINは速い。JOINを嫌う人が多いけど、同じデータにアクセスするならDB側でやった方が圧倒的に速い。データのキャッシュは一貫性の問題がつきまとうので、安易にやるべきではないと思う。

[coolworld]

ぐるぐるSQLってなんだと思ったら、プログラム中のループでSQL実行することなのね。/標準価格とプレミアム価格は、商品価格テーブル1つにまとめたほうがいいと思う。

[hylom]

この例だとテープル設計が良くないので先にそこを改善すべきではと思ってしまう

[coco7t]

ぐるぐるSQLはもちろん良くないけど長々としたSQLもメンテするのうんざりする

[katzchang]

N+1, アプリケーションのメモリを食いやすいのもあって、ある日突然極端にパフォーマンスが落ちがち。基本的には潰した方がいい。

[Amigomr]

ミック先生の『SQL実践入門』あたりを読みなはれ、ということですね

[itchyny]

言いたいことはわかるけどJOINが理想的な方法というのは違和感。pkeyをWHERE INで引けば良い。リレーションを全てJOINしているとリポジトリ層もモデルも腐る。

[uzulla]

「ぐるぐるSQL（ぐるぐる系）」用語確立してるとは（どこか大手の方言かと）。初心者に口頭なら「N+1」「その『N』ってなに？！でも聞けない！」とならなくてよいのかな。けどN+1でおぼえてもらった方が後で楽そうw

[tmatsuu]

繰り返し実行するクエリーは単体だと十分に高速でスロークエリーに引っかからない（けど何度も呼び出すから塵積って遅い）ことがあるから厄介。performance_schemaやpg_stat_statementsを活用しよう。

[saikyo_tongaricorn]

ミック氏のSQL本にぐるぐる系SQLとガツン系SQLって表現されてるし鬼の首を獲ったかのようにN+1な、って言われても

[rasterson]

出力先をテーブルにすればSQL文1つで出来そう。(javaプログラミングは要らない)

[rryu]

サマリの表みたいなのをアプリ側の実装だけで作るとこうなりがちである。DBにビューを作れば大体解決するのだが、ビューをマイグレーションできるORMは意外と無いので面倒ではある。

[sawat]

N+1問題のことね → （追記) コメント欄参照。なるほど…

[takopons]

昔、新人が書いたSQLがfor文内にOPENとSELECTとCLOSEがあって、DBの接続と切断をfor文の外で1回だけやるように助言したら処理が格段に速くなって、その新人が感動していた。でも、もしかしたらfor文も実は不要だったかも。

[satomi_hanten]

NESTED LOOPの話かと思ったら違った。特に変えてないのに急に遅くなった→元々の実装に問題があるってパターンかと。

[takc923]

ただのN+1問題だった

[jiro68]

プログラマーがDBの特性を理解していないので起こる問題。このケースではDBだが、ネットワークとかプログラム実効速度とレイテンシーが桁違いに遅いモジュールを意識していないと起こりがち。

[D_first]

たびたび話題に上がるなこれ。ぐるぐる系とかガツン系って言い回しはミック氏の本が最初なんだろうか。ただ、ぐるぐる系を批判していたミック氏も、後年にぐるぐる系にも一定の価値があると再評価してた気がする

[Shinwiki]

PDCAが流行ったから、物事を考える手段がそれにつられてるとか…

[doko]

SQLじゃないけど、確かにプログラミングでやたらぐるぐるさせがちだなぁ。APIとか文法でなんとかなる言語が多いのに

[su_zu_ki_1010]

テーブル設計、見積もった件数と実際の件数の乖離、当初の想定からかけ離れた仕様、など色々あるのでぐるぐるSQLが悪いとは一概には言えない。まぁ新規開発時に遭遇するレスポンスの悪さはたいていはぐるぐるSQL。

[findup]

ぐるぐるSQLって割と一般的な言い方なの…？／ミック氏の名前は知ってるが本読んでないしそんなに経典のように読んでて当然な本なのか

[rck10]

とはいえ、基本的に機能のモジュール強度と呼び出しオーバーヘッドはトレードオフだからなぁ。「１要件向けの最強の部品」は再利用性は皆無でしょ。どこかで性能を諦めないと、いつまでもモノリシックのまま。

[masatomo-m]

最後にもあるマイクロジョブ化・オンデマンド処理化によって非効率になるのはあるあるだなあ。バッチだと10～1000倍速いけど、1件ずつ回すのはそれはそれでresume・異常対応しやすいというのはあるのでどっちもあり得る

[noseld]

ぐるぐるSQLって言うの知らなかった。

[yamadar]

SQLはいちどシビアな現場で経験積んでおくとその後の役に立つと思う

[hiroomi]

“マイクロサービスとかいって、REST API 呼び出しをループで大量に実行しようとする”

[oakbow]

他ブコメと同じく実行計画の話かと思ったらもっと浅いところだった。N+1じゃないけどなんでもORMで解決できるわけじゃないので、ちゃんと発行されるSQLは見なくちゃ駄目。この程度のSQLで長いとか言うのも駄目。

[greencoffeemaker]

ここ1、2年のプロジェクトでパフォーマンス問題が出たのは確かにぐるぐるSQLが多かった。アプリ側での対応必要よね。

[dowhile]

ORMが勝手に生成するねん

[uxoru]

気持ちはわかるが可読性を考えた結果、プロジージャーでぐるぐるSQLを書かざるを得ない時とかあったなあ

[nekochiyo]

昔はORMが無かったから少なかったのだろうな

[Fushihara]

一撃SQL書くのは気持ちいいけどメンテナンスが地獄なんだよね

[tsutsumi154]

ケースバイケースだとは思うけど例に挙げられてるケースならループさせない方法を考えるかな イテレーションしたほうが楽なケースもあるとは思う

[kagehiens]

インデックスちゃんと使える構成だったら100万件だろうと1000万件だろうと余裕よ！！ただし、ソートし直しをさせられる使い方である場合を除く。

[tohokuaiki]

ブコメで皆さんが思い思いの「ぐるぐるSQL」を綴られてますが、私のインプレッションはウロボロスでした。