RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita

"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に

[theatrical]

どうでもいいけど、これタイトルにRDBじゃなくてMySQLにしたほうが良いと思う。かなりMySQL特有の話だしね。

[ata00000]

適切なタイトルは「MySQL - 実例で学ぶ、Nested Loop Joinが遅くなる理屈と対処法」ではなかろうか。主語が大きい案件？

[kamipo]

わかりやすい。InnoDBの場合はセカンダリインデックスはプライマリキーのキー値を含むのでtag_idを複合キーに含めなくてもよいですよ。

[shag]

RDB と言いつつ MySQL specific な話をする人は unix と言いつつ Linux specific な話をする人と似ている。と思いました。

[twotiger]

主要RDBMSってOracle、SQLServer、PostgreSQL、MySQLあたりになると思うけど、この中でMySQLだけが特別変わっているというか、SQL準拠がレベル低い。MySQLが当たり前と思わないでほしい。

[tagomoris]

#isucon でJOINをこれ見よがしに入れておくと参加者が大量に釣れて便利

[yuku_t]

最近得た知見をまとめた; タイトルを修正してNLJだけだってことが分かるように変更した

[n314]

普段PostgreSQL使ってると、joinが遅い論調にピンとこない。

[nilab]

「"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います」

[d14a]

MySQLの例

[efcl]

ループでのjoin問題

[taegawa]

“Using temporary”

[reitanigawa]

改めて考える

[tolkine9999h]

一口にインデックスと言っても、クラスタ化か非クラスタ化で全然違うとおもうけど。タグの新着記事の例だと、クラスタ化インデックスにしないと、あんまり意味ないのでは？

[nfunato]

"join"

[moccos_info]

MySQLの実装との関係が深い話

[Dai_Kamijo]

MySQL の Nested Loop Join について詳しく解説 / “RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita” — Takuto Wada (@t_wada) July 22, 2015 from Twitter https://twitter.com/Dai_Kamijo July 24, 2015 at 02:24PM via IFTTT

[t-wada]

MySQL の Nested Loop Join について詳しく解説

[naga_sawa]

JOINの実行の実際

[nakaearth]

なるほどー

[satomi_hanten]

MySQLはNested Loopしか実装されてないってマジですか

[gontta]

いい

[papiro]

MySQLでのJOINに関するパフォーマンスの考え方。RDBよく分かってないな・・

[InoHiro]

主にMySQLでのJoinについて

[anoworl]

> 実はMySQLに関していうとNLJ（とその亜種）しか実装されていません。 > OracleとPostgreSQLは3つとも実装されています。

[mapk0y]

tag_id は primary_key じゃないので必要なら追加するのは正しいと思ってたけどどうなんだろう。

[takaesu]

DBのJOIN/検索の仕組みが分かりやすい

[did2]

あとで読むかも

[dekasasaki]

JOIN悪論ってMySQL特化の話である可能性が極めて高いね。

[hiro14aki]

パフォーマンス

[ksss9]

最高っぽい

[sonots]

mysql

[tengo1985]

PostgreSQLの場合、JOINの組み合わせのコスト計算は、動的計画法で計算する量を減らしてたけど、そのへんの実装は同じようなもんなのかな。