ラジオの話題11：20行しか返さないのに、なぜ遅い？
今日の話題：①LIMIT 20の下にある仕事 → ②indexがあるのに全表走査 → ③速いSQLを100回送る。
気になったところから自由に。順番や時間は決めず、話しやすい話題だけ拾って構いません。
1. LIMIT 20の下にある仕事
Section titled “1. LIMIT 20の下にある仕事”話を広げるメモ
- 上位20行を決めるために、何行を比べた？
- Sortが20行返したから、20行しか読んでいない？
小ネタ：入力行数と出力行数
top-NのSortでも候補を大量に読む場合がある。一方、絞り込みと順序をindexが供給すれば早期終了できる場合がある。物理的に20行だけ触ったという保証とは別。
話の芯：返した量と、調べた量は違う。
2. indexがあるのに全表走査
Section titled “2. indexがあるのに全表走査”話を広げるメモ
- ほとんどの行が条件に一致したら？
- ANALYZE後にSeq Scanへ変わるのは悪化？
小ネタ：選択と実測
plannerは見積もりでplanを選ぶ。多数の行に一致するなら順次走査が候補になる。教材の実験では統計更新でplanは変わったが、高速化までは観測していない。
話の芯：planの名前だけで勝敗を決めない。
3. 速いSQLを100回送る
Section titled “3. 速いSQLを100回送る”話を広げるメモ
- 一回8msでも直列100回なら約800msの演習例。
- slow query一覧だけ見ていたら気づける？
小ネタ：N+1とNested Loop
アプリからSQLを何度も送るN+1と、DB内のJOIN方式であるNested Loopは別。SQLの単発時間に加えて、リクエスト当たりの発行回数を見る。
話の芯：一回の速さと、全体の仕事量を並べる。
最後に一言、話すなら
Section titled “最後に一言、話すなら”「この話を、次に調査や設計をするときどう思い出したいか？」
このメモの材料
Section titled “このメモの材料”既存の学習振り返り教材から話題を選び、AIが小ネタとして再構成しました。説明・設計例と、本人の回答・実測の記録は別です。数値例は記載した仮定に基づくもので、本人の本番実績ではありません。
定義の詳細・前提・一次資料・対象版・確認日は元の教材を参照してください。今回の作成では新しい実験・学習評価は行っていません。