[ACC2000] Access 2000 でクエリを最適化する方法

文書翻訳 文書翻訳
文書番号: 209126 - 対象製品
この記事は、以前は次の ID で公開されていました: JP209126
すべて展開する | すべて折りたたむ

目次

概要

この資料では、Access 2000 でクエリのパフォーマンスを最適化する方法について説明しています。

詳細

Microsoft Jet データベース エンジン (以下 Jet) のクエリ オプティマイザ、クエリの時間測定、パフォーマンスの解析、およびクエリのパフォーマンスを向上させるための設計上のヒントについて説明しています。

この資料は、リンク テーブルではなく、ローカル テーブルが格納されたデータベースを対象としています。この情報はテーブルがリンクされている場合にも適用できますが、リンク テーブルでは、他の要因によってもクエリのパフォーマンスに影響が生じます。

リンク テーブルのパフォーマンスを改善する方法の詳細については、以下の米国 「サポート技術情報」 (Microsoft Knowledge Base) を参照してください。

208858 ACC2000: Optimizing for Client/Server Performance

209551 ACC2000: Tips for Optimizing Queries on Attached SQL Tables

クエリ オプティマイザ

Jet にはいくつかのコンポーネントが含まれますが、クエリにおいて最も重要となる (かつ最も複雑な) コンポーネントはオプティマイザです。オプティマイザはコストベースで動作します。つまり、各クエリ タスクに時間コストを割り当てた後、最もコストの低いタスクのリストを選択して目的の結果セットを生成します。実行に時間のかかるタスクほど、コストが高いと判断されます。

オプティマイザでは、クエリで使用する計画を決定するために統計情報が使われます。これらの統計情報は、テーブルに含まれるレコード数、テーブルに含まれるデータ ページ数、テーブルの場所、インデックスが存在するかどうか、インデックスが一意かどうかなどの情報に基づきます。オプティマイザは、これらの統計情報を基にして、特定のクエリを処理するために最適な内部クエリ計画を選択します。

この統計情報は、クエリがコンパイルされるたびに更新されます。クエリ (または基になるテーブル) に変更を保存したり、データベースを圧縮したりすると、クエリにはコンパイルが必要なことを示すフラグが設定されます。コンパイルの必要を示すフラグがクエリに付いている場合は、そのクエリの次回実行時にコンパイルと統計情報の更新が行われます。

データベースに大量のレコードを追加した場合は、クエリを開いて保存し、再コンパイルすることをお勧めします。たとえば、クエリをデザインし、小規模なサンプル データのセットを使用してテストしたら、他のレコードをデータベースに追加した後、そのクエリを再コンパイルします。これにより、使用中のクエリのパフォーマンスが最適化されます。

注意 : Jet の最適化方式を確認したり、クエリの最適化方法を指定したりすることはできません。ただし、Database Documenter を使用することにより、インデックスが存在するかどうか、インデックスが一意かどうかを確認できます。

Database Documenter の情報については、以下の米国「サポート技術情報」 (Microsoft Knowledge Base) を参照してください。
207782 ACC2000: Error Using Database Documenter If Objects Are Open

クエリの時間測定

選択クエリの時間の測定値として大きな意味を持つのは、最初のデータの画面が表示されるまでの時間と、最後のレコードが取得されるまでの時間の 2 つです。クエリから返される画面が 1 つだけの場合、これら 2 つの時間の測定値は同じです。クエリから多数のレコードが返される場合は、これらの時間の測定値が大きく異なる可能性があります。

データシート ビューで選択クエリを表示したとき、2 つの測定値が同じ場合は、データの画面とクエリから返されたレコード数が表示されます。レコード数は、"レコード: 1 / N" のように示されます。Jet でクエリが完了するよりも先に最初のデータ画面が取得された場合は、データの画面は表示されますが、"レコード: 1 / N" の N の部分は表示されません。クエリが完了するか、画面を下方向へスクロールして最後のレコードを表示するまで、 N の値は表示されません。

この動作は、クエリを完了してからデータを表示するか、またはデータの表示を開始してからクエリを完了するかという、2 つのパフォーマンスの一方を Jet が選択した結果です。どちらが使われるかを制御することはできません。最も効率的な方法が Jet によって選択されます。

パフォーマンスの解析

Access 95、Access 97、または Access 2000 を使用している場合は、パフォーマンス最適化ツールを使用してデータベースのクエリを解析できます。クエリのパフォーマンスの解析は Jet と密接に関連しているため、パフォーマンス最適化ツールがインデックスの追加を提案するのは、Jet によるクエリの最適化で実際にインデックスが使われる場合だけです。パフォーマンス最適化ツールを使用すると、後述の「クエリのパフォーマンスを改善するためのヒント」よりも、特定のデータベースに適したパフォーマンスのヒントが提供される可能性があります。

Access 95 または Access 2000 でパフォーマンス最適化ツールを実行するには、[ツール] メニューの [解析] をクリックし、[パフォーマンスの最適化] をクリックします。

クエリのパフォーマンスを改善するためのヒント

クエリのパフォーマンスを改善するには、次のヒントを試します。

  • データベースを最適化します。最適化を行うと、テーブルのレコードが再構成され、テーブルの主キーに従って近接するデータベース ページに配置されるため、クエリを高速化できます。これにより、全レコードを取得するときに読み取る必要のあるデータベース ページ数が最小限になり、テーブルのレコードに対するシーケンシャル スキャンのパフォーマンスが向上します。データベースを最適化したら、各クエリを実行し、更新済みのテーブル統計情報を使用して再コンパイルします。
  • クエリの条件を設定するために使われるフィールドと、結合の両側のインデックス フィールドにすべてインデックスを付けるか、これらのフィールド間にリレーションシップを作成します。リレーションシップを作成すると、Jet は、外部キーにインデックスが付いていなければインデックスを作成し、それ以外の場合は既存のインデックスを使用します。

    注意 : ハード ディスク上の Access テーブルと ODBC サーバー テーブルを結合するクエリは、Access テーブルが小さく、かつ結合されるフィールドにインデックスが付いていれば、Jet によって自動的に最適化されます。この場合、Access は必要なレコードだけをサーバーに要求するため、パフォーマンスが向上します。異なるソースからテーブルを結合する場合は、結合フィールドにインデックスを付けるようにします。
  • テーブルのフィールドを定義するときは、そのフィールドのデータに合わせて最小のデータ型を選択します。さらに、結合する予定のあるフィールドには、同じまたは類似したデータ型を設定します。たとえば、オートナンバー型と数値型 ([フィールドサイズ] プロパティが [長整数型] に設定されている場合) を使用します。
  • クエリの作成時には必要なフィールドだけを追加します。条件を設定するために使われるフィールドを非表示にするには、そのフィールドの [表示] チェック ボックスを オフ にします。
  • フォームやレポートの [レコードソース] プロパティに SQL ステートメントを設定する場合は、SQL ステートメントをクエリとして保存し、[レコードソース] プロパティにクエリ名を設定します。
  • サブクエリでは演算フィールドを使用しないようにします。演算フィールドが含まれるクエリを別のクエリに追加すると、演算フィールドの式が原因となってトップレベルのクエリのパフォーマンスが低下することがあります。次の例では、クエリ Q1 がクエリ Q2 の入力として使われています。
    Q1: SELECT IIF([MyColumn]="Yes","Order Confirmed","Order Not Confirmed") AS X FROM MyTable;
    Q2: SELECT * FROM Q1 WHERE X="Order Confirmed";
    Q1 の IIf 式は最適化できないため、Q2 も最適化できません。最適化できない式がサブクエリにネストされている場合は、クエリ全体が最適化できなくなります。

    このクエリを構築する別の方法を次に示します。
    Q1: SELECT * FROM MyTable WHERE MyColumn = "Yes";
    出力に式を含める必要がある場合は、それらの式をフォームまたはレポート上のコントロールに配置します。たとえば、上記のクエリをパラメータ クエリに変更し、MyColumn 値の入力を求めるようにして、そのクエリに基づくフォームまたはレポートを作成します。フォームまたはレポートには、MyColumn の値に応じて "Hello" や "Goodbye" などを表示する演算コントロールを追加できます。

    クエリは次のように構築します。
    PARAMETERS [To see confirmed orders, enter Yes. To see unconfirmed orders, enter No.] Text;
    SELECT *
    FROM MyTable
    WHERE MyColumn = [To see confirmed orders, enter Yes. To see unconfirmed orders, enter No.];
    フォームまたはレポート上の演算コントロールには、次のように入力します。
    =IIF([MyColumn]="Yes","Order Confirmed","Order Not Confirmed")
  • 結合フィールドの値でレコードをグループ化する場合は、合計するフィールド (集計を求めるフィールド) と同じテーブルにあるフィールドを Group By 句に指定します。たとえば、Northwind サンプル データベースで [受注明細] テーブルの [数量] フィールドを合計し、[受注コード] でグループ化するクエリを作成するには、Group By 句に [受注明細] テーブルの [受注コード] フィールドを指定するのが望ましい方法です。Group By 句に [受注] テーブルの [受注コード] フィールドを指定すると、 Access では、集計の実行後に必要なフィールドだけが結合されるのではなく、最初にすべてのレコードが結合され、その後で集計が実行されることになります。

    より高速化するには、Group By 句で使用するフィールドをできるだけ少なくします。または、可能であれば First 関数を使用します。

    集計クエリに結合が含まれる場合は、1 つのクエリでレコードをグループ化し、そのクエリを、結合する別のクエリに追加する方法を検討します。クエリによっては、これでパフォーマンスが向上することがあります。
  • 演算フィールドや非インデックス フィールドには、できるだけクエリの抽出条件を設定しないようにします。代わりに、最適化が可能な条件式を使用します。
  • テーブル間に一対多のリレーションシップが設定されているとき、その結合に使われているフィールドの値を条件によって抽出する場合は、結合の "一" 側と "多" 側のうち、どちらに条件を設定すればより高速にクエリが動作するかをテストします。クエリによっては、結合の "多" 側に条件を追加するのではなく、"一" 側に追加する方がパフォーマンスが向上します。
  • 並べ替えに使用するフィールドにインデックスを付けます。
  • データが頻繁に変更されない場合は、テーブル作成クエリを使用して、クエリの結果からテーブルを作成します。フォーム、レポート、または別のクエリでは、基になるデータとしてクエリではなく結果のテーブルを使用し、ここで推奨されているガイドラインに従ってインデックスを追加します。
  • DLookup 関数のような定義域集計関数は使わないようにして、クエリに含まれないテーブルのデータにアクセスすることを避けます。定義域集計関数は Access に固有の機能であるため、これらの関数を使用するクエリは Jet で最適化できません。代わりに、関数からアクセスしていたテーブルをクエリに追加するか、サブクエリを作成します。
  • クロス集計クエリを作成する場合は、できるだけ固定の列見出しを使用します。
  • インデックス フィールドに対しては、Between...And、In、および = 演算子を使用します。
  • ODBC データ ソースに対して一括更新クエリを行う場合は、[エラー時中止] プロパティを [はい] に設定することによって、サーバーのパフォーマンスを最適化します。

関連情報

Access 2000 のパフォーマンスの最適化の関連情報の詳細については、[ヘルプ] メニューの [Microsoft Access ヘルプ] をクリックします。次に、Office アシスタントまたはアンサー ウィザードにパフォーマンスの最適化と入力し、[検索] をクリックして表示されるトピックを参照してください。
インデックスの使用の情報については、以下の米国「サポート技術情報」 (Microsoft Knowledge Base) を参照してください。
209564 ACC2000: Compound Indexes Must Restrict First Indexed Field
この資料は米国 Microsoft Corporation から提供されている Knowledge Base の Article ID 209126 (最終更新日 2000-11-29) をもとに作成したものです。

プロパティ

文書番号: 209126 - 最終更新日: 2001年12月3日 - リビジョン: 1.0
この資料は以下の製品について記述したものです。
  • Microsoft Access 2000 Standard Edition
キーワード:?
kbhowto kbinfo ac2k access2000 kbdta query kbusage 最適化 acc2000 クエリ 9.0 KB209126
"Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。"

フィードバック

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com