前月1か月の集計なのに重い｜非パーティション表と並列フルスキャン | 現役データベースエンジニアの迷わないラビリンス

この記事で分かること

見た目は次のような SQL でも、いつも触っている表と比べて極端に遅いことがあります。

「1年分なら重いのも分かる」と思いがちですが、実務で痛いのはここです。
前月のデータであっても、対象となるテーブルが大きな非パーティショニングされた詳細データである場合、他テーブル比で極端に遅くなる。

初見のテーブルや、普段あまり使っていないテーブルで起きやすいです。
いつもの軽さの感覚が通じないので、「SQLが悪いのか？」と寄り道しやすい、という場面です。

さらに悪いのが、直近3か月が欲しいときの次の発想です。

3か月いっぺんは時間がかかりそうだから、1か月分の検索を3つに分割して並行実行しよう。

非パーティション表では、各本がだいたい フルスキャン相当 になります。
1本のフルスキャンが3本同時に走るので、スロットをまとめて食うことがあります。期間を分けたつもりが、負荷だけ倍増、というパターンです。

※ 本稿のプロジェクトID・データセット名・テーブル名・列名は説明用の仮名です。

初見、またはほとんど触ったことのない表に、「前月の件数を出すだけ」の SQL を流す。
いつものテーブルならすぐ返る感覚なのに、こちらは極端に遅い。
あとから定義を見ると、日付カラムでパーティション分割されていなかった——というパターンです。

1年分なら「まあ重いよな」で納得しやすいのですが
前月1か月でも、他のテーブルと比べて明らかに遅い場合と、その原因は対象のテーブルにあると気づきやすいです。

記事のポイントは「なぜフルスキャンになるか」の講義ではなく、非パーティション表かどうかを見抜くことが重要です。あわせて、3並列で悪化させないことです。

相手はだいたい次の部類です。

SQL が短いこと・対象期間が1か月であることと、読む量が小さいことは別です。

直近3か月分が欲しいとき、現場では次の二択になりがちです。

やり方	起きやすいこと
3か月を1本の SQL で集計	重い。ただしフルスキャンは（だいたい）1本
1か月×3本を並列実行	「早く終わるかも」と思いやすい。非パーティションならフルスキャンが3本同時に発生することになり、スロットを同時に圧迫しやすい

「期間を分割して実行する」は、パーティションがある表では有効なことがあります。
無い表では、分けても読む量がほとんど減らず、並列にした分だけ資源を食う、という整理です。

並列で投げたくなったら、先に次を確認します。

テーブル詳細で、パーティションの有無を見る
ドライランで、前月1か月分のスキャン量を確認する
大きいなら、次を選ぶ
- 期間をさらに狭くして試す（週・日など）
- 重い前提で1本投げ、結果は履歴であとから見る
- 「3か月欲しいから3並列」は、フルスキャン3本になっていないか疑う
- 繰り返し使用する場合は結果テーブル化や元表の再設計を検討すること。

根本対策は、設計側のパーティション化や事前集計テーブルです。
「いま画面で待っているジョブ」への対処は別問題で、Studio を閉じても履歴から結果を取れる、という話は別記事にまとめています。

失敗: 初めて見る表では、前月1か月分でも重くなる可能性がある。
回避: 実行前に表の特徴とドライランを見る。他テーブル比で極端なら定義を疑う
失敗: 3か月がいっぺんは遅いから、1か月×3並列にする（非パーティションのまま）
回避: 1本あたりのスキャン見込みを見てから決める。フルスキャン近いなら並列はスロットを食うだけ、になりやすい
失敗: SQLの問題だけでなく、テーブルの設計にも注意が必要です。
回避: パーティションとスキャン量を先に確認する