Javaエンジニアとして業務システムを開発していると、どうしても避けられないのがデータベースのパフォーマンス問題。
中でもOracleを使用している場合、「SQLが遅い」と言われたときに最初に見るべきは実行計画(Execution Plan)です。
今回は、私が実務で培った実行計画の基本的な読み解き方と、着目すべきポイントを共有します。
実行計画は、OracleがSQLをどのように処理するかをステップごとに示したものです。
たとえば、どのテーブルをどの順序でアクセスするか、どのインデックスを使用するか、結合順序などが記載されます。
EXPLAIN PLAN FOR ~
やDBMS_XPLAN.DISPLAY_CURSOR
で確認できますが、実務では後者(DISPLAY_CURSOR)で実際に実行された計画を確認するのが一般的です。
アクセスパス:TABLE ACCESS FULL
が頻発している場合は要注意。テーブルフルスキャンが適切か、それともインデックスが使えるべきかを検討します。
FILTER PREDICATESとACCESS PREDICATESの違い:ACCESS PREDICATES
はインデックスを利用した条件、FILTER PREDICATES
はインデックス後にフィルタされる条件。後者ばかりなら、インデックスが正しく使われていない可能性があります。
コストと行数予測:コスト(COST)や予測行数(ROWS)も目安にはなりますが、Oracleの統計情報が古いと正確でないため、統計情報の最新化も忘れずに。
あるJava業務システムで、受注明細テーブルに対する検索が極端に遅くなっていました。実行計画を確認するとNESTED LOOPS
でループしており、内側のテーブルがTABLE ACCESS FULL
されていました。
原因は、JOINキーにインデックスが存在していなかったこと。インデックスを追加することで、実行時間が10秒→0.2秒に改善されました。
SQLチューニングは「魔法」ではなく、「論理と観察」の積み重ねです。実行計画はその出発点です。
Javaのロジックだけで解決できない問題に直面したとき、DBの内部動作に一歩踏み込むことで、本質的なボトルネックに気づけることもあります。
Oracleの実行計画に慣れることは、本物のフルスタックエンジニアへの第一歩です。