ラジオの話題12:日付で分けたデータを、ユーザーで探す
今日の話題:①捨てやすい分け方と、探しやすい分け方 → ②一つのSQLで、いくつも探す → ③少数返すだけでも、子は多い。
気になったところから自由に。順番や時間は決めず、話しやすい話題だけ拾って構いません。
1. 捨てやすい分け方と、探しやすい分け方
Section titled “1. 捨てやすい分け方と、探しやすい分け方”話を広げるメモ
- 日付で分割すれば古い範囲を扱いやすい。
- 全期間のuser検索には日付条件がない。
小ネタ:partition pruning
不要なpartitionを除外するには、分割境界と検索条件の関係が重要。日付で分けただけではuser検索で過去の月を飛ばせるとは限らない。
話の芯:保持の軸と、検索の軸は一致する?
2. 一つのSQLで、いくつも探す
Section titled “2. 一つのSQLで、いくつも探す”話を広げるメモ
- 各月のindexを調べる計画。
- SQL一つだからscanも一回、ではない。
小ネタ:AppendとMerge Append
Appendは子の結果を連結し、全体の順序は保証しない。Merge Appendは順序付きの子の候補を比較して次の行を選ぶ。全件を集めて再sortする処理とは違う。
話の芯:DBの中で増える仕事を想像する。
3. 少数返すだけでも、子は多い
Section titled “3. 少数返すだけでも、子は多い”話を広げるメモ
- 最初の1行を選ぶために各月の先頭候補を見る。
- 月単位と日単位の管理対象数の違い。
小ネタ:最初の行までの費用
Merge Appendは複数の子の先頭候補を必要とし得る。LIMITが小さくても、多数partitionの計画・探索の負担が消えるわけではない。小さな実験の時間を個数だけで比例拡大しない。
話の芯:結果の小ささだけで、探索の軽さを決めない。
最後に一言、話すなら
Section titled “最後に一言、話すなら”「この話を、次に調査や設計をするときどう思い出したいか?」
このメモの材料
Section titled “このメモの材料”既存の学習振り返り教材から話題を選び、AIが小ネタとして再構成しました。説明・設計例と、本人の回答・実測の記録は別です。数値例は記載した仮定に基づくもので、本人の本番実績ではありません。
定義の詳細・前提・一次資料・対象版・確認日は元の教材を参照してください。今回の作成では新しい実験・学習評価は行っていません。