あなたの遅延はどこから？ SQLから！ 〜患部に止まってすぐ効くSQLレビューチェックリスト 年初め特大サービス号〜 - ANDPAD Tech Blog

あけましておめでとうございます！ 今年は異世界放浪メシのアニメが放送されるらしいので楽しみなバックエンドの原田 (tomtwinkle)です。 内部で運用しているSQLレビューチェックリストの一部を抽出し思いつきで追記して行った結果、結構な分量になってしまいました。 暇な時でも流し読みして頂けるとありがたいです。 Motivation SQLレビュー観点 大きくSQLが変更される修正の際にはEXPLAINをレビュー内容に加える 検索のキーにINDEXを使用しているか SQL発行回数がN+1(1+N)の構造になっていないか サブクエリを利用したSQLはパフォーマンス要チェック Viewの利用は基本的に禁止 CROSS JOINは禁止 WHERE句で十分に絞った検索をしているか 必要なcolumnだけSELECTしているか レコード数だけ必要な場合にCOUNT用のSQLを発行しているか 集計関

[tomtwinkle]

書きました / EXISTSの件は実際にそれで遅くなった事があったのでレビュー項目に入っている感じですね。ちなみにAmazon Aurora MySQL 2（MySQL 5.7 互換）です。

[cpw]

タイトル勝ち

[fusionstar]

そんなに多数の RDB 使ったことないんだけど、 EXISTS より IN のほうが速いなんてことあるの?

[nmcli]

サブクエリ自体がボトルネックになる場合、 PostgreSQL だと IN ( SELECT column FROM ... ) 句より EXISTS( SELECT 1 FROM ... ) のほうが速いイメージあるなあ。 DB によるのかなぁ。

[railute]

なぜ禁止事項としてあげられがちが、またRDBMSのどの実装がその禁止理由になるのかがあまり分かってないリストかな。例えば目に付きやすいところでEXISTS句の実行速度は実装の影響でRDBMSによるとしかいえないし。

[anepan]

昔から見てるページとほぼ同じ内容なのでそろそろ静的解析ツールとかで何とかしてほしい。 https://mickindex.sakura.ne.jp/database/db_optimize.html

[twotiger]

この会社で使ってるケースではそうだってだけだと思う。VIEW禁止とかCROSS JOIN禁止とか。マスタを参照するだけならそうかもしれないけど、統計を出したい場合はそうはいかない

[knjname]

EXISTS（セミジョイン）の実行結果がJOINに比べてクソだとしたらDBMSがクソなんだと思う /　アンチジョインをNOT INで書いてNULLでハマるからINはなるべく避ける派

[daira4000]

ちゃんとMySQLの話だって書いて欲しい。他のRDBMSだと気にしなくてよかったり逆にパフォーマンス悪くするのもある。まずはEXPLAINを見よう。

[takeag]

最近のmysqlのver8ではEXISTSも早くなったため、無理してIN使わなくて良くなったはず。

[getcha]

タイトルいいなw と思って開いてトップコメを見て、私がしなければいけない事はスターを上げる事以外何も無くなった。

[tsukinouragawa]

あとでよむ…！

[hogashi]

おもしろい / “書き込み順序とIDが同列でソート出来ない場合、挿入や検索の際に複数のリーフページに偏りがないため、 複数のTreeに対して検索が走ってしまい”

[halfrack]

内容もいい

[tmatsuu]

無茶なDISTINCTに似たようなものだけど、DISTINCTとGROUP BYを併用しているクエリーはもっと良い感じに書ける、というのは自分の経験則です。こちらからは以上です。

[Magicant]

Cross join に where 句を付けたら inner join と等価だけどそっちは禁止しないってことは単に書き方の趣味の問題なんかな

[otchy210]

考えてみればずいぶん長いこと SQL 書いてないが、ここに書かれてるようなことは概ねまだ覚えてた。というか見たらあー懐かしいっていう感情になった。必要になってもまだ書けるかな？書けるといいな。

[twry]

タイトル優勝

[GARAPON]

チルノのパーフェクトSQL教室　だれかたのむ！

[PrivateIntMain]

主にAPIのボトルネックがSQLにならないようにする話なので、監視統計調査などDB単体で済む時は当然VIEWも作ってよいし、ヘビーなクエリ(雑なクエリではない)を流すこともある。

[kisiritooru]

あなた〜の下痢に狙いをキメて、便・THE・ブロック♪

[roshi]

VIEW禁止とEXISTS句とIN句の使い方は場合によるけど他はだいたい同意かも。加えるならCTE（共通テーブル式）に置き換えられるか検討するとかかなー。

[ty356trt5]

EXISTSは何とも言えんが、他はまぁRDB界で古から伝わる知恵達って感じ。とりあえずVIEWに無駄にJOINする奴は死すべし。慈悲は無い。

[buzztaiki]

わりとオプティマイザによるみたいなところもある。

[tutuz]

タイトルにつられちゃった、秀逸すぎるｗ 中身はまだ読んでないｗ

[fashi]

実用的だ

[Hamukoro]

ネタが古いのにターゲットユーザーに的確にリーチしてるのずるい。

[shag]

view, mview 禁止されたら生きていけない

[chess-news]

うどんげ

[paperot]

いいキャッチコピーなんだなあ

[oakbow]

サブクエリテーブルって初めて聞いたけど、インラインビューって言い方が一般的では…/むしろJOINやサブクエリ使って発行回数減らすので、分割は違和感。データ量が物凄いところはこちらのパターン増えるとは思うけど

[taruhachi]

VIEWの使用禁止以外は妥当かな。特定のVIEWのみに参照権限をつけたアカウントを渡すとかできて便利。追記:EXISTSとかの実装はまぁ、自分の使う製品の特性を調べようね。という話。

[Andrion]

列挙されていて参考になる