処理が重いクエリの高速化を図ろうと試みたことがあるなら、「;実行計画を確認すればいい」とアドバイスされた経験がおそらくあるでしょう。それは的確なアドバイスなのですが、これまで実行計画を見たことがない人にとっては、その出力内容は宇宙人の言葉のように思えるかもしれません。この記事では、実行計画とは何か、その内容をどう読み解くか、そして最新のツールがどのようにしてその作業の負担を大幅に軽減してくれるかを解説します。
クエリ実行計画（Query Execution Plan）とは？
SQLクエリを実行する際、データベースはただいきなり動作を開始して、無作為にテーブルをスキャンし始めるわけではありません。その代わりに、主要なデータベースエンジンに組み込まれている機能であるクエリ最適化エンジン（query optimizer）が、データを取得するための数十、あるいは数百もの可能な戦略を分析し、それぞれのコストを見積もり、最も高速であると判断した選択肢を採用します。実行計画とは、その判断をデータベースが記録したものです。
これはGPSのルート案内と似ています。A地点からB地点への移動を依頼すると、GPSは最適な道路の順序を計算します。そして、GPSが提示する「曲がり角ごとの道順」こそが、その実行計画なのです。この計画を理解することで、自分が高速道路を走っているのか未舗装の道を進んでいるのかがわかるだけなく、それ以上重要なこととして、どこにボトルネック（渋滞箇所）があるかも把握できるのです。
実行計画の生成方法
ほとんどのデータベースでは、クエリの先頭に EXPLAIN キーワードを付けることで実行計画を生成します。MySQL、PostgreSQL、MariaDB、SQLite はいずれもこの構文をサポートしていますが、SQL サーバーでは「SET SHOWPLAN_ALL ON」を使用するか、ツール内のグラフィカルな実行計画ボタンを使用します。出力形式はデータベースによって異なりますが、その根底にある概念はすべて共通しています。
たとえば、EXPLAIN SELECT * FROM orders WHERE customer_id = 42 を実行しても、実際にはクエリは実行されません。その代わりに、データベースがどのようにクエリを実行しようとしているかの説明が返されます。この説明を基に、最適化が必要かどうかを判断することができます。
押さえるべきポイント
実行計画は、一度に大量の情報を表示するため、最初はとっつきにくいかも知れません。でも、心配ご無用です。たいてい、動作の問題の原因は、いくつかの典型的な兆候から特定できます。
まず初めにチェックすべきポイントは、「フルテーブルスキャン」です。MySQLでは「code>ALL」、PostgreSQLでは「Seq Scan」と表示されることが多いです。これは、データベースが必要な行を見つけるために表の全行を読み込んでいることを意味します。これは、利用可能な資料目録を使わずに、図書館の本を一冊ずつ片っ端から探すようなものです。小さな表であれば問題ありませんが、大きな表であればまず間違いなく問題となるでしょう。
次に、「見込み行数（estimated row counts）」に注目してください。最適化エンジン（optimizer）の判断はこうした「見込み値」に基づいて行われるため、見込み値が実際の値から大きく外れている場合、それによって選択された実行計画は非効率的である可能性があります。大幅に実際の値とかけ離れている場合は、大抵は統計情報の古さが原因です。これは、データベースに応じて ANALYZE または UPDATE STATISTICS コマンドを実行することで修正できます。
最後に、「結合タイプ（join types）」を確認してください。ネストループ結合（Nested Loop Join）は、組み合わせる表の片方（一方の表）が小さい場合において非常に有効なのに対し、ハッシュ結合（Hash Join）は、より大規模な表のデータセットに最適です。もし実行計画が、2つの大規模な表に対してネストループ結合を選択している場合は、適切なインデックスを追加するか、クエリを再構築することで、最適化エンジンがより効率的なアプローチを選択するよう促すことができるでしょう。
Navicatの「図解解説（Visual Explain）」機能
未加工のEXPLAIN出力をプレーンテキストとして読み解くには、慣れと根気が必要です。Navicat 17では、この課題を解決するため、「図解解説（Visual Explain）」機能を大幅に強化しました。この機能により、実行計画のデータをビジュアル化された図解表示に転換し、一目で内容を把握できるように設計されています。
テキストの行を一つひとつ読み解く代わりに、「実行計画のビジュアルフロー」として表示され、各操作がノードとして視覚化されます。Navicatは処理コストが高く非効率な操作をハイライト表示するため、注意を払うべき計画の部分に視線が自然と誘導されます。頭の中で計算する必要はもうありません！未加工データでの作業を好むユーザーのために、Navicatでは同じ計画データを複数の形式で表示します。ビジュアル、JSON、テキスト、統計ビューのいずれも利用可能で、確認したい内容に応じて切り替えることができます。
このマルチフォーマット対応は、異なるデータベースプラットフォームをまたいで作業する際に特に役立ちます。各エンジンによってEXPLAINの出力形式が異なるためです。Navicatはこの操作体験を統一しており、MySQL、PostgreSQL、またはその他のサポート対象データベースのいずれを使用する場合でも、実行プランを確認するためのワークフローは一貫しています。
実行計画を分析するための実践的なアプローチ
実行計画に対する理解を深める最良の方法は、まず自分がすでに理解しているクエリを選び、その実行計画を生成し、それを段階を追って追跡することです。インデックスを追加して、もう一度EXPLAINを実行してみてください。実行計画がリアルタイムで変化していく様子が見て取れ、スキーマの変更に対して最適化エンジンがどのように反応するかを直感的に把握できるようになります。
経験を積むにつれて、フルテーブルスキャンや誤った行数見積もりを即座に見抜くことが、自然と身についてきます。実行計画は、もはやブラックボックスのような謎めいた情報量の塊ではなく、本来の役割である「データベースが何をしているのか、そしてその理由」を明らかに説明する存在として捉えられるようになるでしょう。
結論
実行計画は、開発者やDBAにとって最も強力なパフォーマンス分析ツールの一つであり、見た目の印象よりもはるかに扱いやすいものです。フルテーブルスキャンがどのようなものか、行数の見込み値が何を意味するのか、そして結合タイプごとの違いを理解すれば、クエリのパフォーマンス問題の原因を特定するために必要な知識の大部分を手にしたことになります。その知識を、 Navicatに組み込まれた「EXPLAIN」の可視化機能のようなツールと組み合わせれば、想像以上に短時間で迷いから抜け出し、的確な診断ができるようになります。
