UPPER SYSTEM

スポンサードリンク

統計情報と実行計画(SQLチューニングの基礎)

「統計情報」、「実行計画」…オープン系のシステム構築に1,2年でも携わればこれらの単語を耳にしたことがあるでしょう。

 

実際にシステムをリリースするにあたって、とても重要になってくるのがSQLのパフォーマンスです。

 

機能が素晴らしく、バグがなくても処理が重い画面ではユーザが使う気をなくしてしまいますよね。リクエストを送ってから5秒以上表示までに時間がかかるページは、ユーザが画面表示を待たずに離れてしまうことが多いという統計を見たことが有ります。数年前にそういった状況でしたので、その潮流は今なお続いているでしょう。

 

そこでいわゆる「SQLのパフォーマンスチューニング」が必要になってきますが、その際に分析の指標となるのが「実行計画」です。「統計情報」はデータ特性(一意な値の個数やデータの分布など)や索引の構成、はたまたオブジェクトに対する統計やシステム統計(CPU処理速度や、I/O速度など)に関する情報を指します。

 

適切な統計情報をもとに適切な実行計画が生成され、その情報をもとにSQLのパフォーマンスのチューニングを行っていくのです。

 

<統計情報の取得>

取得対象はTABLE(表)やINDEX(索引)、COLUMN(列)となりますが、ここでは最適な実行計画を生成するための統計情報の取得という観点でご説明します。

 

統計情報を取得する方法(コマンド)は使用するDBによって異なりますので、必要に応じて参考書やWEBサイトで調べましょう。

 

テーブルの統計情報を取得する際にはデータが投入されている状態で行います。先に述べましたように、データの特性によって統計情報ももちろん異なりますので、非現実的なデータであれば非現実的な統計情報になりかねません。統計情報が非現実的であると「実行計画」も非現実的になってしまうので一連の作業が無駄になります。「やりなおし!!!」となってしまいかねませんので、注意したい点ですね。

 

<オプティマイザー>

 

クエリ(SQL)をどのように処理するかを決める機能であり、最適化を行うものです。RDBMSにおいて心臓部や頭脳に例えられるほど重要な部分となります。

 

統計情報を元にオプティマイザーが実行計画をはじきだしてくれるイメージです。

 

<実行計画>

そんなこんなでクエリ最適化のために手がかりとなるのが「実行計画」です。

 

これ自体は内部的な情報ですが、実行計画表と言った形で視覚的に分かるように表示する機能を各々のDBMSがもっています。

 

ORACLEであれば”EXPLAIN PLAN FOR + SQL 文”と言ったスクリプトを流すことで視覚的な実行計画を取得できます。実行計画は実際にクエリを実行するわけではないので即座に取得可能です。クエリの対象データが数百万であろうと…。

 

実際の実行計画はDBMSによって異なるので一概にご説明はできません。それは各々の専門ページを参照すると良いでしょう。ORACLE、DB2、teradataと経験してきた身として私見を申しますと「ネットで検索してヒントを得る+何とかして読み解く能力」によって乗り越える必要があります。(ありました。)まあこれはSQLチューニングに限った話ではありませんね、常に新しい問題と向かい合っていくのがSE・PGの宿命でしょうか。

 

出力された実行計画からクエリを分析し、インデックスを貼り替えたりテーブル同士の結合方法を変更したりして再度実行計画を出力。改善されていれば実際のモジュールとして反映させ、実際のオンライン機能上から重さが改善されているか(クエリがスピーディーに処理されているか)確認するという流れになります。

 

 

  このエントリーをはてなブックマークに追加

 

スポンサードリンク

関連ページ

Accessの肥大化と破損を防ぐ方法
Accessのファイルは放っておいても肥大化します。予防と対策として「データベースの最適化」が必要です。共有ファイルを管理する場合、必見です。