ユーザーがクエリー（通常は構造化クエリー言語（SQL）文として記述される）を送信すると、データベースは要求されたデータを取得するための複数の方法を評価します。この意思決定プロセスは、クエリー・オプティマイザーと呼ばれるコンポーネントによって処理され、最も効率的な実行戦略が選択されます。
最新のデータベース管理システム（DBMS）は、コストベースのオプティマイザーを使用して、さまざまな実行ストラテジーのコストを推定し、最も効率的なオプションを選択します。このプロセスのため、同一の成果を生成する2つのデータベース・クエリーの実行時間が大きく異なる可能性があり（多くの場合、ミリ秒単位）、クエリーの性能と応答時間に影響を及ぼします。
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
アプリケーションは、情報を迅速かつ一貫性をもって取得するためにデータベースに依存しています。クエリーが非効率である場合、データベースはテーブル・スキャン、レコードの並べ替え、または大規模なデータセットの結合に不要な時間を費やす可能性があります。このような遅延は、アプリケーション・プログラミング・インターフェース（API）や分析ワークロードの速度を低下させ、全体的なユーザーエクスペリエンスを低下させるボトルネックを引き起こします。
組織がより多くのデータを収集するにつれて、データベースは、膨大な量、多様なデータ型、より要求の厳しいクエリー・パターンによって、ますます複雑化するワークロードをサポートする必要があります。
世界のデータスフィアは2028年までに393.9ゼタバイトに達すると予想されており、かつては数千行を処理していたクエリーも、最終的には数百万から数十億行を処理するようになるかもしれません。クエリー最適化により、データ量が増えてワークロードの複雑さが増大しても、効率的なクエリーが可能になるため、拡張性が向上します。
効率的な実行計画により、問い合わせの処理に必要なリソースも削減されます。すべてのデータベースオペレーションは、中央処理装置（CPU）サイクルやディスクインプット/アウトプット（I/O）など、データを処理するためのシステム・リソースを必要とします。
最適化されていないクエリーはリソースを大量に消費し、同じ成果を生成するために必要以上の処理が必要になります。リソースの使用量が価格に直接影響するクラウド環境では、リソース消費量の増加は高コストになる可能性があります。
機械学習、リアルタイム分析、検索拡張生成（RAG）、AIをサポートする最新のデータ・プラットフォームは、大量のデータへの高速かつ信頼性の高いアクセスに依存しています。クエリー最適化により、これらのシステムは予算を損なうことなく、リアルタイムの意思決定をサポートするのに十分な速さで関連情報を取得できるようになります。
データベース・オプティマイザーは、潜在的な実行ストラテジーを評価する際に、いくつかのアプローチを使用できます。初期のデータベース・システムでは、あらかじめ定義されたルールを適用して、クエリー構造に基づいて実行計画を決定するルールベースの最適化がよく使用されていました。
最新のDBMSは通常、コストベースの最適化を優先し、複数の可能な実行戦略を評価し、それぞれに必要なリソースを見積もります。一部のシステムには、ヒューリスティック・ベースの手法も組み込まれており、実用的なガイドラインを適用して、クエリー計画を簡素化し、最適化オーバーヘッドを削減します。
最適化アプローチを使用するにせよ、オプティマイザーが潜在的な実行ストラテジーを評価する方法は、次の技術的概念によって形作られます。
クエリー・オプティマイザーは、効率的な実行計画を選択するデータベース・コンポーネントであり、多くの場合、コストベースの最適化手法を使用します。リレーショナル・データベースでは、このプロセスは、データベース・エンジンがSQLクエリーを実行する最も効率的な方法を決定するのに役立ちます。
コストベースのオプティマイザーは、固定されたルールに依存するのではなく、データの特性とクエリー構造を分析して、最も効率的なアプローチを決定します。この柔軟性により、データベースはデータセットやワークロードの進化に合わせて実行戦略を適応させることができます。
オプティマイザーは、さまざまな実行計画のコストを推定するために、データベース統計に大きく依存しています。統計は、次のような保管されたデータの主な特性を表します。
これらの統計情報を基に、オプティマイザーはクエリーから返される行数と、異なる実行ストラテジーで必要な作業量を推定できます。統計が古くなったり不正確になったりすると、オプティマイザーは非効率的な実行計画を選択する可能性があります。
カーディナリティー推定とは、クエリーの各ステップから成果として得られる行数を予測することを指します。例えば、クエリーが次のようなWHERE句を使用して行をフィルタリングするとします。
WHERE region = ‘North America’
オプティマイザーは、そのフィルターに一致するレコードの数を推定する必要があります。
これらの推定は、いくつかの重要な意思決定に影響を与えます。オプティマイザーは、これらを使用して、テーブルを結合する順序、最も効率的な結合順序、使用する結合アルゴリズム、またはテーブル全体をスキャンする代わりにインデックス・スキャンを使用するかどうかを決定できます。
インデックスを使用すると、データベースはテーブル全体をスキャンするよりも効率的に特定のデータを見つけることができます。オプティマイザーはインデックスを使用して、データ検索に必要な作業量を削減します。
一般的なアクセス・パスには、テーブル内のすべての行を読み取る完全なテーブル・スキャンがあります。インデックス・スキャン：インデックス構造を通じて行を読み取ります。インデックスシーク：インデックス・ルックアップを使用して特定の行を取得します。インデックスのみのスキャン：基礎となるテーブルにはアクセスせずにインデックスから直接データを取得します。
適切なアクセス・パスを選択すると、特に大きなテーブルを扱う場合に、クエリーの実行に必要な作業量を大幅に削減できます。
多くのクエリーは複数のテーブルからデータを取得します。この場合、オプティマイザーはこれらのテーブルをどのように組み合わせるかを決定する必要があります。一般的な結合アルゴリズムには、次のものがあります。
オプティマイザーは、データ・サイズ、使用可能なインデックス、推定された行数などの要素に基づいて、これらのアルゴリズムの中から選択を行います。
クエリー最適化がどのように機能するかを理解するためには、SQLを宣言型言語と考察することが役に立ちます。つまり、データをどのように取得するかではなく、どのデータを取得する必要があるかを記述します。
オプティマイザーは、リクエストを最も効率的に実行する方法を決定する責任を負います。これを実現するために、ほとんどのデータベースはいくつかの最適化手順に従います。
クエリーが送信されると、データベースはまずSQLステートメントを解析し、その構文を検証します。この段階で、システムは参照されたテーブル、列、インデックスが存在し、クエリー構造が有効であることを確認します。
また、データベース・スキーマ内の関連オブジェクトが利用可能であることも検証します。このステップにより、リクエストを最適化または実行する前に、データベースがリクエストを確実に理解できるようになります。
解析後、データベースはクエリーをより効率的に実行できる同等の形式に書き直す場合があります。これらのトランスフォーメーションにより、クエリーの成果は維持されながら、実行構造が改善されます。一般的なクエリー書き換え手法には、次のようなものがあります。
これらのトランスフォーメーションにより、オプティマイザーは最終的な成果を変更することなく、より効率的なストラテジーを探索します。また、不要なデータの処理を制限するのにも役立ちます。
クエリーが書き換えられると、オプティマイザーは複数の潜在的な実行計画を生成します。各プランは、要求されたデータを取得するための異なるストラテジーを表します。
計画は、使用されるインデックス、テーブルが結合される順序、または中間成果の処理方法によって異なる場合があります。比較的単純なクエリーでも、いくつかの可能な実行戦略を生み出すことができます。
例えば、過去1週間の注文を取得する1つのクエリーには、いくつかのオプションがあります。注文テーブルをスキャンしてその後行をフィルタリングしたり、注文日のインデックスを使用して最近のレコードをすばやく見つけたり、関連する顧客や製品に結合する前に最初にデータセットを絞り込んだりすることができます。
次に、オプティマイザーは、コスト・モデルを使用して各候補プランを評価します。コスト・モデルは、特定の計画を実行するためにデータベースが実行する必要がある作業量を推定します。これらの推定値では通常、次のような要素が考慮されます。
データベースは正確なコストを事前に知ることができないため、データについて保管されている統計情報に依存しています。その情報は、オプティマイザーが可能性のある処理時間を推定し、どのアルゴリズムとサポートするデータ構造が最も適切であるかを判断するのに役立ちます。
候補プランを評価した後、オプティマイザーは推定コストが最も低いプランを選択します。この選択されたストラテジーが、データベースがクエリーを実行する際にオペレーションの順序を記述するクエリー実行計画になります。
効率的な実行計画には通常、テーブル・スキャン、結合、ソート、集計（GROUP BYやLEFT JOINを使用）などの操作が含まれます。ユーザーは、EXPLAINプランをレビューして、オプティマイザーが要求されたデータを取得するために実行する手順を確認できます。
最新のデータベース・オプティマイザーが高度であるにもかかわらず、いくつかの要因によってクエリー最適化が困難になっている可能性があります。
クエリー最適化は自動的に行われますが、開発者、管理者、データ・エンジニアはいくつかの最適化手法を通じて性能を向上させることができます。
インデックスは、頻繁に使用されるフィルターや結合条件をサポートすると、クエリーの性能を大幅に向上させることができます。適切に設計されたインデックスを使用すると、オプティマイザーはテーブル全体をスキャンすることなく特定の行を素早く取得できます。ただし、過剰なインデックス作成は、データ更新中にオーバーヘッドが発生する可能性があります。したがって、インデックスは、読み取り性能と書き込み効率のバランスを取るように慎重に設計する必要があります。
オプティマイザーは統計を使用してクエリー・コストを推定するため、効率的な実行計画を維持するためには、統計を最新の状態に保つことが不可欠です。統計を定期的に更新することで、オプティマイザーはデータ分布とテーブルのサイズに関する正確な情報を得ることができます。
クエリー実行の早い段階でフィルターを適用すると、クエリーの後で処理する必要がある行数が減ります。中間成果が小さいほど、クエリーの実行速度を向上させることができます。このため、早期に選択的フィルターを適用するクエリーの方が効率的に実行されることがよくあります。
多数のテーブルを結合するクエリーは、複雑なクエリーや同様に複雑な実行計画を生成することがあります。結合が不要または冗長である場合は、結合を削除することで実行の複雑さを大幅に軽減できます。場合によっては、非正規化によって結合の必要性が減り、パフォーマンスが向上することもありますが、ストレージ使用量やデータ冗長性が増加する可能性があります。
不要な列を取得するクエリーにより、読み取って処理しなければならないデータの量が増加します。結果セットを必要なフィールドのみに制限すると、メモリー使用量とディスクI/O操作が削減されます。この小さな調整により、大規模なデータセットのパフォーマンスが大幅に向上します。
一部の環境では、パーティショニングは非常に大きなテーブルをより管理しやすいセグメントに分割するのに役立ち、キャッシュは頻繁にアクセスされる成果に対する繰り返しのデータベース作業を軽減できます。これらのアプローチは普遍的な修正プログラムではありませんが、他の最適化ストラテジーを補完することができます。
多くのデータベース・プラットフォームには、開発者と管理者がクエリーのパフォーマンスを分析し、非効率的な実行計画を特定するのに役立つ組み込みツールも提供されています。
例えば、SQL Server Management Studio（SSMS）はクエリー性能の監視やボトルネックの特定に役立ちます。MySQL Workbenchはクエリー計画の解析や実行最適化のためのツールを提供します。Oracle SQL Tuning AdvisorはSQLクエリーの改善のための自動推奨を生成することができます。
クエリー最適化とクエリー・チューニングは密接に関連していますが、異なるプロセスを表しています。
クエリー最適化とは、データベースが効率的な実行ストラテジーを決定するために使用する自動プロセスを指します。
対照的に、クエリー・チューニングとは、クエリーの性能を向上させるための手作業を指します。これらの作業には、非効率なクエリーの書き換え、新しいインデックスの作成、統計の更新、データベース構成設定の調整などが含まれる場合があります。
実際には、クエリー最適化とクエリー・チューニングは多くの場合、連携してデータベースの性能を向上させます。これらを組み合わせることで、本番システムでのSQLの性能を向上させるための実用的な最適化ストラテジーのセットが形成されます。
クエリー最適化は、従来のコストベースの計画を超えて進化しています。最新のデータベース・システムには、クエリーの分析と実行の方法が改善されるよう、オートメーション、適応型実行、人工知能が組み込まれるようになりました。
新たな方向性の1つは、システムが性能を継続的に監視し、問題に自動的に対応する自律型データベース機能の開発です。これらのシステムは、事後対応型のトラブルシューティングに全面的に頼るのではなく、ワークロードの動作、クエリー性能、システム信号を分析し、潜在的な性能の問題を早期に特定し、是正措置を推奨します。
多くの自律型データベース・アーキテクチャーは、これらの機能を3つの運用領域に整理しており、多くの場合AIエージェントがその機能を担っています。
これらのエージェント型機能は、データベース・チームが重要なシステムの監視を維持しながら、オートメーションが明確に定義されたオペレーション・タスクを処理する、ヒューマン・イン・ザ・ループ・モデルの中で動作するように設計されています。
組織がデータ・プラットフォームの拡張を続け、AI駆動型のアプリケーションを採用するにつれて、自身を監視、最適化、保守できるシステムが、信頼性の高いデータベースの性能を確保する上でますます重要な役割を果たすようになります。
watsonx.dataを使用すると、オープンでハイブリッドな、管理されたデータ・ストアを通じて、データがどこに保存されていても、すべてのデータを使用して分析とAIを拡張できます。
あらゆるクラウド上でデータベースを利用してアプリケーション、分析、生成AIを実行
適切な戦略、データ、セキュリティ、ガバナンスを整え、AIを効果的に拡張します。