DB MySQL

MySQL オプティマイザ クエリ実行一連の流れ

MySQLオプティマイザは、MySQLデータベース管理システムのコンポーネントで、データベースクエリを最も効率的に実行する方法を決定する役割を担っています。

クエリの構造、利用可能なインデックスや統計情報を分析し、クエリの処理に必要な時間とリソースを最小化する実行計画を生成する目的で作られています。

MySQL オプティマイザの細かい動きには、クエリを最適化するために従う一連のステップを押さえておく必要があります。

構文解析と構文チェック

オプティマイザはまずSQLクエリを解析し、シンタックスチェックを行い、クエリが有効で整形されていることを確認します。

クエリに構文エラーがある場合、オプティマイザはエラーメッセージを生成します。

クエリの前処理

構文チェックの後、オプティマイザーはクエリの前処理を行います。

この処理では、コメントの削除、空白の正規化、クエリをパースツリーと呼ばれる内部表現に変換するなどの作業が行われます。

テーブルとカラムの解決

オプティマイザは、クエリで参照されているテーブルとカラムを特定します。

データベーススキーマをチェックして、テーブルとカラムの存在を確認し、カラム名のあいまいさを解決します。

コストモデルと統計

オプティマイザは、統計とコストモデルに基づいて、さまざまな実行プランのコストを推定します。

統計には、行数、インデックス、カーディナリティなど、テーブル内のデータ分布に関する情報が含まれます。

コストモデルは、テーブルスキャン、インデックス検索、結合など、さまざまな操作にコストを割り当てます。

クエリの変換

オプティマイザはクエリに様々な変換を施し、実行計画を改善することがあります。

これには、結合の順序変更、述語のプッシュダウン、サブクエリのアンネスティングなど、操作回数の削減やデータアクセスの向上を目的とする変換が含まれます。

インデックス選択

オプティマイザは、クエリ対象のテーブルで利用可能なインデックスを考慮し、使用するインデックスがある場合は、それを決定する。述語の選択性を評価し、各インデックスを使用する際のコストを見積もる。

その目的は、ディスクの読み込み回数を最小にし、クエリの性能を向上させるインデックスを選択することです。

結合の最適化

クエリが複数のテーブル間の結合を含む場合、オプティマイザはテーブルを結合する順序を決定する。

様々な結合アルゴリズム(入れ子ループ、ハッシュ結合、マージ結合など)を検討し、統計情報と利用可能なインデックスに基づいてそのコストを推定します。

コストベースのプラン評価

オプティマイザは、これまでのステップに基づき複数の実行プラン候補を生成し、各プランにコスト推定値を割り当てる。

そして、異なるプランのコストを比較し、最もコストが低いものを最適なプランとして選択します。

プランの実行

オプティマイザは最適な実行プランを決定すると、そのプランをMySQLクエリ・エグゼキュータに渡し、プランに従ってクエリを実行させます。

最後に

MySQLオプティマイザの細かい動きには、複雑なアルゴリズムとヒューリスティックのセットが含まれており、正確な動作と最適化戦略は、MySQLのバージョンや構成設定によって異なる場合があることに留意する必要があります。

オプティマイザの目標は効率的なプランを見つけることですが、クエリ最適化特有の複雑さにより、常に絶対的なベストプランが見つかるとは限りません。

  • この記事を書いた人

朝倉卍丸

シングルモルトスコッチなどのお土産を持ってきた人を助けるのが好きです。サービスの分割が重要ですが、まあ昔ながらの方法でやりたいこともありますよね。

よく読まれている記事

条件の0=0は全てが正であるを意味するSQL 1

SQLの条件に0=0のような記述を見かけます。 変わった書き方の条件ですが、これは「全てが正である」事を意味しており、結合条件の場合はCROSS JOINと同じです。 下記の例で言えば、結合するsub ...

DISTINCTを使わないで重複排除を考えるSQL 2

SQLのDISTINCTはEXISTSとかGROUP BYでなんとかする事もできます。 DISTINCTは暗黙的なソートがされますが、何のDBを使うにせよ過去のバージョンならともかく、最近のバージョン ...

RFC 5322に準拠させた正規表現言語別 3

RFC5322で定義されている正規表現を、各言語の正規表現に変化させた形になります。 完全な電子メール正規表現は存在しないので、結局のところ何かの公式基準に従っていたとしても、自分が携わるサービスのル ...

-DB, MySQL