テーブルパーティショニング設計とメンテナンス（レンジ・リスト・ハッシュ）

パーティショニングは、論理的に扱う表を複数の領域へ分け、検索範囲と保守単位を調整する設計です。分割しただけですべての検索が高速になるわけではありません。検索条件、保存期間、偏り、制約、追加・削除の手順を合わせて設計します。

分割方式を業務と合わせる

ハッシュ分割しても、複数領域を同じディスクに置けば物理I/Oが自動的に分散するわけではありません。特定顧客にアクセスが集中する場合、そのキーは同じ領域に集中します。分割数を増やすと管理対象や計画作成の負担も増えるため、数だけで高速化を判断しません。

プルーニングは分割キーの境界と条件を対応させる

9月の日時だけを必要とするなら、日時>=9月1日 AND 日時<10月1日の半開区間で条件を表します。月末の時刻や小数秒を列挙する必要がなく、隣の月と重複しません。タイムゾーンを含む列の場合は、業務上の月をどの時間帯で決めるかも確認します。

SELECT COUNT(*) FROM 視聴ログ
WHERE 視聴日時 >= TIMESTAMP '2026-09-01 00:00:00'
  AND 視聴日時 < TIMESTAMP '2026-10-01 00:00:00';

列にDATE_TRUNCなどの関数を適用すると、通常の日時レンジ分割との対応を判断しにくい場合があります。ただし式で分割する機能や最適化はDBMSに依存し、「関数があれば常に全走査」とは言えません。PostgreSQLでは実行時プルーニングもあり、パラメータ利用が常に無効というわけでもありません。EXPLAINで対象領域を確認します。

索引・一意性の実装は製品別に確認する

各パーティションの索引は、その領域の保守と合わせて扱いやすくなります。全領域をまたぐグローバル索引を提供する製品では、表全体の検索・一意性を実現できる一方、分割の保守時に追加処理が必要になることがあります。保守で必ずすべて無効になるわけではなく、製品の版や操作・オプションに依存します。

PostgreSQL 18の宣言的パーティショニングでは、親の索引は子索引をまとめる構造です。全体のUNIQUEやPRIMARY KEYを付けるには、分割キーに関する条件があり、対象の分割キー列を含む必要があります。分割日付を足してキーを作れば、注文番号単独の全期間一意性まで保証されると誤解しないようにします。

古い領域の削除とロック

行ごとのDELETEに比べ、古い領域の切離しや削除は処理量を減らせる場合があります。ただし、必ず0.1秒で完了する、ログが不要、稼働中の他処理に影響しない、という保証はありません。DDLロック、長時間トランザクション、参照制約、レプリカ、バックアップやアーカイブの必要性を確認します。

PostgreSQLで独立した子表を削除する例はDROP TABLE 視聴ログ_2023_09です。運用上いったん切り離すならALTER TABLE 視聴ログ DETACH PARTITION 視聴ログ_2023_09を使う方法があります。ALTER TABLE ... DROP PARTITIONという他製品の構文と混ぜないようにします。

今後の領域作成、保存期間の境界、DEFAULT領域へ入った行の移動、日付の変更が別領域への移動を伴う場合の負荷も計画します。分割を検索性能だけの対策として導入せず、保守作業が確実に実行できるかを含めて評価します。

演習1：月境界の条件

条件：視聴日時で月次レンジ分割。9月末の小数秒を含む全行を集計する。

問い：期間の条件を答えよう。

解答例：9月1日以上、10月1日未満。

根拠：終了を翌月初日の未満にすると精度に関係なく9月を含められる。

演習2：削除前の確認

条件：保存期間を過ぎた子表をDROPして古いログを削除する。

問い：「瞬時で無影響」とみなす前に確認する項目を説明しよう。（35字以内）

解答例：DDLロックと参照制約、保存要件を確認する。（22字）

根拠：実行時間と他処理への影響は運用条件によって変わる。

復習で確かめること

例の数値や業務条件を変えて同じ結論になるか確認してください。用語の定義だけでなく、問題文のどの条件から、どの制約・SQL・対策を選んだのかを自分の言葉で説明できれば、次の過去問に進みます。

出典と仕様を確認する

IPA：DBシラバス Ver.4.1

PostgreSQL 18：パーティション

関連するテーマ

B+木インデックス設計と検索性能最適化（最左プレフィックス・カバリング）

物理データベースサイジング（レコード長・ページ設計・容量見積り）