この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。参照元の情報をもとに整理していますが、筆者による実機確認は行っていません。
検証ステータス：unverified（実機未確認）
Amazon Aurora DSQLにおいて、テーブル内の特定条件を満たす行のみを対象とする「部分インデックス（Partial Indexes）」のサポートが発表されました。これにより、過去ログや完了データなどの大規模な履歴行を除外し、現在進行中のアクティブなデータのみを対象にした軽量なインデックスを構築して検索性能向上とストレージコスト削減が図れます。
部分インデックス（Partial Index）の概要と目的
データベースのテーブルは運用期間が長くなるにつれて行数が増加し、インデックス自体のサイズも肥大化していきます。一般的なインデックスではテーブル全体の全行に対してキーが生成されるため、検索頻度が低い過去のデータもインデックス領域を消費し続けます。
一次情報によると、Amazon Aurora DSQLでサポートされた部分インデックスは、テーブル全体のすべての行を格納するのではなく、特定の条件に合致するサブセット（qualifying rows）のみを対象としてインデックスを構築できる機能です。
インデックスに格納されるデータ量が絞り込まれるため、以下の2つの大きな効果が得られると一次情報に記載されています。
クエリパフォーマンスの向上: 検索時に走査するインデックスデータ量が減少するため、対象行を読み出す際のI/O効率が高まります。
インデックスストレージコストの削減: 条件外の膨大な行がインデックスから除外されるため、インデックスが消費するストレージ容量を抑えられます。
部分インデックスの評価と適用判断の流れ
Aurora DSQLがクエリ実行時に部分インデックスを利用するかどうかは、クエリの検索条件（フィルタ）がインデックス作成時に指定された条件内に収まっているかどうかに依存します。
一次情報に基づく判断フローは以下の通りです。
flowchart TD
A[クライアントからのクエリ発行] --> B{クエリのフィルタ条件が部分インデックスのWHERE条件内に収まるか？}
B -- 収まる --> C[部分インデックスを参照して読み取りデータ量を削減]
B -- 収まらない --> D[部分インデックスは使用されずテーブル走査または別インデックスを使用]
Aurora DSQLでは、実行されるクエリの抽出条件が、部分インデックス定義時の条件式と論理的に一致またはその範囲内に包含されている場合にのみ、オプティマイザによって部分インデックスが選択されます。
部分インデックスが有効な利用シナリオ
一次情報では、典型的な利用シナリオとして「長期間にわたる完了済み注文（completed orders）の中に含まれる少数の未完了注文（open orders）」のような関係性が挙げられています。
業務システムでよく見られる構造として、以下のような特性を持つテーブルが該当します。
作業対象セット（Working Set）の局所化: 日常的に更新や参照が行われるのは直近のステータスを持つ行だけであり、処理が終了した行は参照頻度が極端に低いケース。
ライフサイクルの偏り: ステータスが「未処理」「配送中」など特定の状態にある期間は短く、「完了」「キャンセル」といった状態の行が大半を占めるケース。
データ量の不均衡: 年月の経過とともに累積した完了履歴が全体の9割以上を占め、現在処理対象となるデータが全体の数パーセントに過ぎないケース。
このようなテーブルに対して全行インデックスを作成すると、大半が検索対象にならないデータで占められてしまいます。部分インデックスを利用して未完了注文などの作業対象セットのみを抽出対象にすることで、テーブル全体が成長してもインデックスサイズを小さく維持できると一次情報で説明されています。
定義方法とクエリ最適化のポイント
部分インデックスの作成は、従来のインデックス作成構文に条件句を追加することで行います。
一次情報によると、CREATE INDEX 文に WHERE 句を付与することで、対象となる作業セットのみを絞り込んだインデックスを定義します。
インデックス定義の構文イメージ
一次情報で示されているアプローチに基づくと、未完了のステータスのみを抽出する構文は次のような形式になります。
-- 保存名: create_partial_index.sql -- 実行前提: Aurora DSQL上で注文テーブル（orders）が存在すること -- 期待できる確認内容: statusが'open'の行のみを対象とするインデックスが作成される定義構文 CREATE INDEX idx_orders_open ON orders (order_id) WHERE status = 'open';
この定義により、status = 'open' を満たす行のみがインデックスに登録されます。
クエリ実行時の整合性
インデックスが効果を発揮するためには、検索クエリの記述方法に注意が必要です。一次情報では「クエリのフィルタがインデックスの条件内に収まる場合（whose filter falls within the index’s condition）に、Aurora DSQLが部分インデックスを使用する」と説明されています。
たとえば、上記で作成したインデックスがある場合、クエリ側でも条件を一致させる必要があります。
-- 保存名: query_open_orders.sql -- 実行前提: idx_orders_openインデックスが存在すること -- 期待できる確認内容: インデックスの条件内に収まる検索を行うことで、読み取りデータ量が削減される想定のクエリ SELECT order_id, customer_id, order_date FROM orders WHERE status = 'open' AND customer_id = 12345;
もしクエリ側で WHERE status = 'completed' やステータス条件を指定しない検索を行った場合、その検索条件は部分インデックスの条件外となるため、該当の部分インデックスを利用して走査することはできません。
実務導入における利点と利用時の注意
Aurora DSQLで部分インデックスを採用するにあたり、設計段階で把握しておくべき利点と注意点があります。
主な利点
書き込み負荷の局所化: 条件を満たさないデータ（完了データなど）の追加や更新が行われても、部分インデックス側のメンテナンスは発生しないため、書き込み時のオーバーヘッドを抑えられます。
キャッシュ効率の維持: インデックス自体のサイズが小さくなるため、メモリ上のキャッシュ領域を有効に活用でき、高頻度な参照クエリの応答性が向上します。
コスト削減: Aurora DSQLのストレージ使用量を抑えることができ、長期運用時のインデックス肥大化によるコスト増を抑制できます。
利用時の注意点
インデックス利用の条件一致: アプリケーションから発行されるSQLの抽出条件が、インデックス定義の
WHERE句の論理範囲内に厳密に含まれている必要があります。条件の書き方が異なるとインデックスが無視される可能性があるため、実行計画の確認が重要になります。対象データの動的変化: 更新処理によって条件行から除外される場合（例:
openからcompletedへのステータス変更）、インデックスからの削除とテーブルの更新が同時に発生します。ステータス遷移の頻度やパターンを考慮した設計が求められます。過度な部分インデックス作成の回避: 条件ごとに細かく部分インデックスを作成しすぎると、インデックス管理の複雑さが増すため、真にアクセス頻度が高い作業セットに絞って適用するのが適切です。
提供リージョンと公式ドキュメントの参照先
一次情報によると、Aurora DSQLの部分インデックス機能は、Aurora DSQLが利用可能なすべてのAWSリージョンで提供されています。
構文の細かな仕様や対応する演算子、制約事項などの詳細については、Aurora DSQL User Guideの CREATE INDEX の項目を参照するよう案内されています。
まとめ
Amazon Aurora DSQLの部分インデックス対応について、公式発表の内容を整理しました。
事前に確認すべき点および制約事項は以下の通りです。
インデックス対象の選定: テーブル全体ではなく、特定のステータスや期間など、明確な境界を持つ作業セットが存在するかどうかを事前に設計する。
クエリ条件の整合性: 部分インデックスを利用させるためには、検索クエリのフィルタ条件がインデックスの
WHERE句の範囲内に論理的に収まっている必要がある。実機検証の実施: 一次情報には機能追加の事実と概要が記載されていますが、実際のクエリプランやストレージ削減幅、レイテンシ改善度合いについては、各自の環境で実行計画（EXPLAIN等）を取得して評価する必要がある。
参考情報
source_title: Amazon Aurora DSQL now supports partial indexes
source_url: https://aws.amazon.com/about-aws/whats-new/2026/10/aurora-dsql-partial-indexes/
