「実行計画を取得したが、コストの数字しか見ていない」
「INDEXが使われていないので、すぐ索引を追加すべきだろうか」
SQLの結果が正しくても、処理方法によっては大量のI/Oや長時間の待機が発生します。実行計画は、Oracleなどのデータベースがテーブルへどの順序・方法でアクセスする予定かを示す情報です。
ただし、コストが大きい、FULL SCANがある、INDEXが使われていないという一項目だけで、悪いSQLとは判断できません。取得件数やテーブル規模によっては全表走査が適切な場合もあります。
開発・保守の現場では、実行計画を答えとしてではなく、性能問題の仮説を立てる材料として使います。実績の行数や処理時間、統計情報、データ偏りと合わせて確認することが重要です。
この記事では、若手SEが実行計画を見るときの順番と注意点を解説します。
実行計画は「アクセス・行数・結合」の3点から見る
まず大きなテーブルへのアクセス方法を確認し、次に各処理の推定行数、最後に結合順序と結合方式を見ます。末端からデータが流れ、上位で絞り込みや結合が行われる流れを追います。
実行計画の表示項目や取得方法はDB製品・バージョンで異なります。ここではOracleを想定した一般的な確認観点を紹介します。
| 項目 | 意味 | 確認ポイント |
|---|---|---|
| Operation | アクセス・結合・ソート方法 | FULL、INDEX、NESTED LOOPS、HASH JOIN |
| Rows | オプティマイザの推定行数 | 実績行数と大きくずれていないか |
| Cost | 計画間を比較する相対的な見積り | 単独の絶対評価に使わない |
| Predicate | アクセス条件・絞り込み条件 | 索引条件として使われているか |
| 実績統計 | 実際の行数・時間・I/O | 推定と実績の差を確認する |
実行計画を確認する4ステップ
1．SQLの目的と想定件数を確認する
実行計画を見る前に、SQLが一件検索なのか、大量集計なのか、オンライン処理なのか、夜間バッチなのかを確認します。同じ計画でも、許容される処理時間やI/Oは異なります。
入力条件と想定件数が曖昧なままでは、FULL SCANや結合方式の妥当性を判断できません。
2．大きな表へのアクセス方法を見る
TABLE ACCESS FULLはテーブル全体を読む方式、INDEX RANGE SCANは索引の範囲を使う方式です。ただし、全件の多くを取得するSQLではFULL SCANが適切な場合があります。
索引があるのに使われない場合は、取得割合、統計情報、関数適用、暗黙変換、複合索引の列順などを確認します。
- 大規模表を全表走査していないか
- WHERE句の列に関数を適用していないか
- 列と値のデータ型が一致しているか
- 複合索引の先頭列を条件に使っているか
- 取得割合が高く索引が不利ではないか
3．推定行数と結合順序を確認する
推定行数が実際と大きくずれると、不適切な結合順序や結合方式が選ばれることがあります。小さい結果から結合しているか、中間結果が急増していないかを見ます。
NESTED LOOPSは少量データに向くことが多く、HASH JOINは大量データ結合に使われることが多いですが、方式名だけで良否を決めません。
4．実行実績と統計情報で仮説を検証する
可能な環境では、実際の行数、経過時間、論理I/O、物理I/O、待機を確認します。推定計画だけでは、バインド値やデータ偏りによる差を見落とすことがあります。
統計情報が古い、ヒストグラムが実態と合わない、環境ごとのデータ量が違う場合も計画に影響します。統計更新や索引追加はシステム全体へ影響するため、DBAと相談して進めます。
【確認例】 目的：取引番号で1件取得するオンラインSQL 想定：1件、100ms以内 計画：大規模表をTABLE ACCESS FULL 推定Rows：1 実績Rows：1 仮説：条件列への暗黙変換で索引が使われていない 次の確認：列型・バインド型・Predicate Information
実行計画レビューのテンプレート
計画の貼り付けだけでなく、SQLの目的と判断をセットで残します。
【SQLの目的】 オンライン／バッチ： 想定件数・許容時間： 主な条件： 【実行計画】 大規模表のアクセス： 結合順序・方式： ソート・集計： 推定Rows： 【実績】 実績Rows： 経過時間： I/O・待機： 【差分・仮説】 推定と実績の差： 統計情報： 改善候補と影響：
本番で実測する場合は、SQL実行による負荷を事前に評価し、承認された方法で行います。
よくある失敗と改善方法
| 失敗 | 起こる問題 | 改善方法 |
|---|---|---|
| コストだけで良否を決める | 相対値を絶対評価してしまう | 目的・行数・実績と合わせて見る |
| FULL SCANをすべて悪とする | 大量取得に適した計画を壊す | 取得割合とテーブル規模を確認する |
| すぐ索引を追加する | 更新性能や他SQLへ悪影響を与える | 既存索引・統計・SQL修正を含めて評価する |
若手SE向けチェックリスト
- SQLの目的・想定件数・許容時間を確認した
- 大規模表のアクセス方法を確認した
- Predicateで条件の使われ方を確認した
- 推定行数と中間結果を確認した
- 結合順序・結合方式を確認した
- 可能な範囲で実績行数とI/Oを確認した
- 索引・統計変更の全体影響をDBAと検討した
まとめ：実行計画は性能問題の仮説を作る地図
実行計画は、SQLがどのようにデータへアクセスするかを理解するための地図です。コストや一つのOperationだけで結論を出さず、目的、行数、実績と合わせて読みます。
分からない項目があっても、大きな表のアクセス、推定行数、結合順序の3点を押さえるだけで、調査の質は上がります。
- SQLの目的と想定件数から評価する
- アクセス方法・行数・結合を順に見る
- 推定と実績の差から仮説を検証する
コメント