管理の手引き
ここでは、アプリケーション・プログラムにおいて SQL ステートメントを細かく調整するための考慮事項や指針について説明します。
一般にこれらの指針は、
非常に大きな表のデータにアクセスするために必要なシステム・リソースと時間の使用を最小限に抑えるプログラムを設計するのに役立ちます。
SQL ステートメントをコンパイルするときに起きる最適化の量によっては、
SQL ステートメントを細かく調整する必要がない場合もあります。
SQL コンパイラーでは、SQL をもっと効率的な形式で書き直すことができます。
SQL コンパイラーによる照会書き直しおよび 最適化クラスの調整を参照してください。
また、最適化プログラムによって選択されたアクセス・プランが他の要因 (環境についての考慮事項やシステム・カタログ統計を含む) からも影響を受けるということに注意しておくのも重要なことです。
アプリケーションのパフォーマンスについてベンチマーク・テストを行うと、
アクセス・プランを改善するように調整を行うことができます。
SQL 言語は、非常に柔軟性の高い高水準言語です。
そのため、同じデータを検索するのにも、
いろいろと違う選択ステートメント を作成することができます。
しかし、形式が異なり、最適化のクラスが異なると、
パフォーマンスが変化する可能性があります。
SQL コンパイラー (書き直しと最適化の段階を含む) は、アクセス・プランを選択して、
コーディングされた照会に対する結果セットを生成します。
したがって、以下の指針の多くで示されているように、
必要なデータだけが獲得されるように照会をコーディングする必要があります。
選択ステートメント を使用する際の指針は、
以下のとおりです。
- 選択リスト内で必要な列だけを指定します。
1 つのアスタリスク (*) を使ってすべての列を指定するほうが簡単だとしても、
不必要な処理がなされたり不要な列が戻されたりする可能性があります。
- 述部を使うことによって、選択される行の数を限定して、
応答セットを必要な行だけに制限します。
(述部の種類とそれらがパフォーマンスに与える影響の違いについての詳細は、
述部の用語を参照してください。)
- 使用する行数が戻される行数の合計よりかなり少なくなる場合には、
選択ステートメント に OPTIMIZE FOR を指定してください。
この文節は、アクセス・プランの選択と通信バッファーでブロック化される行数の両方に影響します。
(詳細については、行のブロック化を参照してください。)
- 検出される行数が少ない場合には、
FETCH FIRST n ROWS ONLY 文節の他に OPTIMIZE FOR k ROWS 文節を指定する必要はありません。
ただし、n の値が大きいのではじめの k 行を取り出してから、
後でまた k 行を取り出したい場合には、両方の値を指定してください。
通信バッファーのサイズとして n と k の中で小さいほうが使われます。
SELECT EMPNAME, SALARY FROM EMPLOYEE
ORDER BY SALARY DESC
FETCH FIRST 100 ROWS ONLY
OPTIMIZE FOR 20 ROWS
- FOR READ ONLY (または FOR FETCH ONLY) 文節を指定するなら、
照会が行ブロック化を利用できるようになりパフォーマンスが向上します。
さらに、この文節が指定された照会によって検索される行には排他ロックがかけられないため、
データの並行性も向上します。
また、さらに照会書き直しを行うこともできます。
BLOCKING ALL BIND と一緒に FOR READ ONLY (または FOR FETCH ONLY) 文節を指定するなら、
連合システム内のニックネームに対する照会のパフォーマンスが向上します。
- また、FOR UPDATE OF 文節を指定すると、更新されるカーソルにとっては、
データベース・マネージャーが最初に適切なロック・レベルを選択できるようになり、
潜在的なデッドロック (デッドロックを参照) およびロック変換(ロックの変換を参照) が回避されるため、
パフォーマンスが向上します。
- 可能な限り、数値データ・タイプの変換はしないようにします。
値を比較するとき、同じデータ・タイプの項目を使うようにするなら、
さらに効率的です。
変換が必要な場合、精度の低さのために正確でなくなったり、
実行時変換のためにパフォーマンスが低下したりする可能性があります。
可能なら、以下のデータ・タイプを使用してください。
- 短い列では、可変長文字型ではなく、文字型
- 浮動小数点数や 10 進数ではなく、整数
- 文字ではなく、日時
- 文字ではなく、数値
- 一般に DISTINCT、あるいは ORDER BY などの文節または操作を含む SQL ステートメントでは、
その操作を実行するためにデータを並べ換えることが必要になります。
分類操作が使用される回数を少なくしたい場合は、
これらの文節の指定を必要でなければ省略してください。
- 表に行があるかどうかを調べるときに、次のステートメントは使用せず、
SELECT COUNT(*) FROM TABLENAME
その表が非常に小さいことを知らなければ、
ゼロ以外の値であるかを調べてください。
表が大きくなるにつれ、全行カウントはパフォーマンスに影響するようになります。
むしろ、単一行を選択してみるようにしてください。
これを行うには、カーソルをオープンして 1 行を取り出すか、
または単一行選択 (SELECT INTO) を行います。
(選択ステートメント から複数の行が検出される場合は、
SQLCODE -811 のエラーを必ず調べてください。)
- 更新活動が低調で表が非常に大きい場合には、
述部として頻繁に使用する列に索引を定義してください。
- 複数の述部文節に同じ列が存在する場合には、
IN リストを使用することを考慮してください。
- 大きい IN リストをホスト変数と組み合わせて使用すると、
ホスト変数のサブセットのループインでパフォーマンスが向上する可能性があります。
複数の表にアクセスする選択ステートメント には、
特に以下のことが適用されます。
- 表を結合するときには、結合述部を使用します。
(結合述部とは、1 つの結合において異なる表の 2 つの列を比較することです。)
- 結合述部内で列に対して索引を定義し、
それによって、その結合をさらに効率的に処理できるようにしてください。
これは、複数の表にアクセスする選択ステートメントを含む UPDATE ステートメントおよび DELETE ステートメントにも、
効果があります。
- 可能なら、結合述部で式または OR 文節を使用しないようにします。
この場合、結合技法の中にはデータベース・マネージャーで使用できないものもあるため、
結果として最も効率的な結合方式を選択できない場合があります。
- 可能ならば、区分データベース環境で、
結合された表が両方とも結合列上で区画化されるようにしてください。
詳細については、
結合の概念を参照してください。
さらに、結合や副照会を含む SQL ステートメントのコーディング方法の詳細については、
アプリケーション開発の手引き を参照してください。
[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]