SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話 - Qiita

2020/9/30追記 本記事は元々、「SQL記述者全員が理解すべきSELECT文の実行順序のお話」というタイトルで投稿しておりました。 しかし、知見のある方からのコメントと自分でも調べてみた結果、今回紹介している順序はあくまで論理的な処理順序であり、実行順序とは別物ということがわかりました。 誤った知識を布教してしまい申し訳ございません。 2020/9/30のタイミングで、本記事のタイトルを「SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話」に変更させていただきました。 はじめに 「SQLといえば、エンジニアが扱うスキル」と思われがちですが、最近はマーケターや営業など、非エンジニアの方もSQLを使って、自らデータを抽出し分析する方が増えてきています。 またエンジニアの方でも、ORM任せでなんとなく理解している状態の方もいるのではないでしょうか？ 今回は、そんな方々にこそ

[fa11enprince]

この順でSQL書くように決まってれば、エディタの補完とかしやすかったのになぁとは思う。

[turanukimaru]

SQL書くのは好きなのだが from -> join -> select の順に書けないのだけはめっちゃ不満。from XXX as x join ~ と書いてからカーソルを先頭に戻して select 書いてる…。日本語だったら X と Y を join して a,b,c...を取り出すと書けるのに！

[programmablekinoko]

過度の最適化は悪だと思うタイプ（特にSQLは）なので、このくらいの抽象化された認識の上で最大公約数的効率の良い書き方で良いと思う

[nippondanji]

細かいことを言うと、実行順序じゃなくて評価順序だよね。実際の実行順序は評価順になるとは限らない。

[diveintounlimit]

いやいやlimitかけといたら基本的に速くなるからかけられるならかけたほうがええやろ…実務やったことないんかいな。order by無しのlimitケースもそれなりにあるで…存在確認だけしたい時とか。

[mayumayu_nimolove]

攻撃的な人は精神が子供なんだよ。社会人じゃ無い可能性もあるからスルーするがよろし。

[n_231]

order by句がそもそも無ければlimitで処理時間削減されるだろ。SQL文法上こう書けない理由の説明としてはまぁ許容できるが、それ以外では記述者の理解度が疑わしい。SQLの性能チューニングにはもっと多くの知識が必要。

[sasasin_net]

当然知ってたけど、どこで知ったのか思い出せない。入門書籍ではない。期待と結果が違ったときに、何か調べたのかなぁ。SELECT文の要素を一通り撫でた後で、これを頭の隅に置く機会があるといいですね

[shag]

SQL 界隈はいつも殺伐としてていいな。

[tatsuya_memo]

X句でYが使えないのは文解析の話、処理時間は実行計画の話。筆者は理解しているかもしれないが解析と実行計画、標準SQLと処理系依存の話を混同すれば批判が集まるのは当然。LIMITは標準SQLではないので追記もおかしい。

[ghostbass]

まあ論理的な構造を考えることは大切 /結合条件で table_a(id,name) 1 ---n table_b(id,name,a_id) って定義から from table_a inner join table_b on table_b.a_id = table_a.id って書かれると頭ねじられる< 前世紀ならそう書かねばならなかったかも

[suekunhello]

へー

[weakref]

JOIN、WHEREのどちらが優先されるかは実行計画による。存在確認はEXISTS or 自己結合を使う、order by無しのlimitは使わないかな。

[suimin28]

SQLiteの公式ドキュメント良く参考にしてる　https://sqlite.org/lang_select.html

[beatdjam]

強い言葉をタイトルに付けてそれっぽいこと書くとマサカリが飛んできてより深く理解出来るみたいなやつ

[nmcli]

原理原則はこう、という話だな。パフォーマンスチューニング面でクエリビルダの類に対する苦手意識があり、今なおゴリゴリ SQL 直書きマンである。

[secseek]

初めて知ったときは目からウロコでした。でも、だったらfrom where groupby having select…って順にしてくれりゃよかったのに、と思います

[mas-higa]

イチから自分で書くときは迷わないけど、人が書いた SQL 文を手直しするときはイラッとするやつ。

[dekasasaki]

殺伐としたブコメを見にきた

[o_mega]

SQLは実行順序を隠蔽して、ヒューマンリーダブルに集合演算を記述する手法なんだよなあ、と改めて思うわけです / クエリを解釈して実行計画を建てるのは、エンジン側のしごと

[UhoNiceGuy]

JOINって暗黙のWHEREだよね？プロファイル(explain?)みたらインデックス付いてるところからガシガシ解決していって凄いなと思った(PostgreSQL)

[EngineerYtr]

多様性だな。ちな、ぼくは存在確認に limit じゃなくて count(*) 使う派 (・∀・)

[prjpn]

ためになります

[deamu]

あらそえ…もっとあらそえ…

[tyhe]

"この順でSQL書くように決まってれば、エディタの補完とかしやすかったのに" C# のクエリ式で見た https://docs.microsoft.com/ja-jp/dotnet/csharp/linq/query-expression-basics

[deep_one]

「FROM句でテーブル名に対してASを使用した場合に、他のどの句でも使える」気づいてなかった。

[nharuki]

実行順序じゃなくて評価順序な

[ka-ka_xyz]

ん？「まず実行計画取ってみようぜ」的な話じゃないの？

[versatile]

もうそろそろ db がかしこくなってどんな sql 書いても大丈夫になる

[shukaido170]

LINQ使うようになってから、この辺りの順序構造が何となく理解できてきた気がする

[ducktoon]

これは無理に英語っぽく書こうとするSQLの仕様が良くなかったな。実行順序順に書くようになってればよかった

[zuzu_sion]

SQL触るエンジニアにおいては自然に身につける実行順序のお話し。

[perl-o-pal]

なぜか、この中ではHaving句で困ったことくらいしかないな…。limitは、Oracle中心に触っていたせいか処理系依存なんでしょくらいに考えていた。indexついてないカラムなら、full scanしてorder byしてからじゃ当然遅かろうって。

[diffie]

AS が ORDER BY で使えて GROUP BY が使えないのは、SQL の構文がそうなっているからでしょ。と思って BNF 見たが、よくわからなかった。誰か教えて。https://ronsavage.github.io/SQL/sql-2003-2.bnf.html

[oakbow]

存在確認だけしたいときはexistsとかhavingとか使うんじゃないかと思うけどな。もっと深いところだとオプティマイザ先生の気持ちを考える必要があるけど、とっかかりは別にいいのでは。

[baca-aho-doji]

なんとなくそうだろうと思っていたけど、自分の考えが整理された。この辺ってあんまり習う機会がなかった気がするんだけど、大事よな…

[yood]

カーソルを上下しながら、この順番で書いてるな。言われてみれば、このまま書けた方が手間がないね。