この記事はQiita Engineer Festa 2023 参加記事です。
　

この記事で書くこと

パフォーマンスチューニング（クエリチューニング）を行う際の勘所としてSQLの見直し方を書きます。
　

この記事で書かないこと

あくまで勘所として見る部分を書くので、RDBMSそれぞれ固有のことや深いことは書きません。

SQLが重いからLimitで件数絞ろう！は正しいのか？というお話。

SQLチューニングの勘所

システムのパフォーマンスチューニングを行う上で、ボトルネックになっているのは大体DBのIOの部分ということが多いです。
SQLチューニングの勘所を抑えておくことで、爆速Webサービスを作っていきましょう。

いきなり結論

問い： SQLが重いからLimitで件数絞ろう！は正しいのか？

回答

正しくない！ とは言い切れないが、効果が薄いことが多い。

↑もったいぶってすいません。折りたたみを使ってみたかっただけです。

SQL（SELECT文）の処理される順番を知ろう。

SQLを投げると、パーサーによるSQLの構文チェックのあと、オプティマイザがDBの統計情報を見ながらSQLの実行計画（取得方法）を考えます。
その際の解釈の順番はこんな感じです。

1. from
   　　対象テーブルの指定
2. join
   　　結合するテーブルの指定
3. where
   　　条件絞り込み
4. group by
   　　グループ化
5. sum,avgなど
   　　集合関数
6. having
   　　グループ化後の絞り込み
7. select, distinct
   　　抽出項目の指定
8. order by
   　　並べ替え
9. limit
   　　取得件数の指定

limitで件数を絞るのは最後になりますね。
SQLが重いからチューニングをしよう！と思ったら、できるだけ前段階で効率よく取れるようにすると効果が高いと思います。