LATERALでSQL実行時間を99.75%削減した話 - ANDPAD Tech Blog

こんにちは！ 承認チームでGoエンジニアとしてインターンをしているunagamです。 最近は夏の旅行先として色々な場所を調べるのにハマっています。 今回はあまり馴染みのないSQLのLATERAL句で大幅にAPIを高速化できたので、その学びを共有したいと思います。 概要 APIのボトルネックだったSQLを、LATERAL を使って 94.7ms → 0.236ms（99.75%削減） まで短縮できた。 ただし LATERAL は無条件に速くなるわけではない。外側の行数に比例してコストが増えるという性質があり、条件次第では逆に遅くなる恐れがある。 それでも、リスクを理解した上で適用すれば、LATERAL は強力な改善策になり得る。 経緯 Datadogを用いて承認サーバーのAPIを監視していた際、一週間の合計処理時間が1.6日と他と比べて圧倒的に処理時間を消費しているAPIを見つけました。 処

[short_tanu]

“c.flow_id = f.idのように記述したとします。 この場合、通常のLEFT JOINではスコープ外となり” サブクエリ使わず素直に LEFT JOIN すると良いのでは？

[kagehiens]

MySQLだとオプティマイザがやってくれないのね……。

[fusionstar]

AI にスロークエリ分析してもらうとだいたい LATERAL 使えって言われる。

[kiririmode]

LATERAL の価値は、「外側の少数行をパラメータとして、必要な範囲だけを都度集計する」実行戦略へ反転できる点。高速化は外側の行数が十分小さいというカーディナリティ上の条件に依存。

[adglobe]

SQLの実行時間を99.75%削減というインパクトに驚きました。

[ngyuki]

まあ LATERAL は相関サブクエリみたいなものかと思ってる

[nmcli]

MySQL は通常の外部結合では性能落ちるのは相変わらずなのか。であれば LATERAL 使う表記に頼らざるを得ない。

[mkusaka]

MySQLの`LATERAL`でSQLが94.7ms→0.236msに短縮（99.75%削減）。外側行数でO(N)増の注意点も解説。

[uunfo]

LATERAL使わずに改善できそうだけどな

[mohno]

計測は大事だね。「「全件を計算してから少しだけ使う」サブクエリを見つけたら、LATERAL で「必要な分だけ計算する」に変えられないかを疑ってみる価値があります」/使うことはないだろうけど（←オイ）

[circled]

PostgreSQLだが、複数条件のJOIN時に複合インデックスが入っていなかったり、並び順が間違っていたりで遅くなって、適切なインデックス入れると1000倍高速：3秒→3.4msみたいなパターンもあるのでな

[nguyen-oi]

LATERALのメリットだけでなく外側の行数比例で遅くなるリスクまで丁寧に解説されてて良記事。前提条件の監視がセットなのも実用的

[sezemi]

インターン中の unagam さんによるパフォーマンスチューニングの続編です！ LATERAL 知らんかった ...