4

Access 2003 DBを使用していて、そのパフォーマンスを向上させたいと考えています。昨日、実行プラン（Show Plan）に関する記事を読み、今日、このクエリに対してshowPlanを実行しました。

SELECT tb_bauteile_Basis.*
FROM tb_bauteile_Basis
ORDER BY tb_bauteile_Basis.Name;

Nameフィールドにインデックスを付けて、そのクエリプランを表示します。

 Inputs to Query -
Table 'tb_bauteile_Basis'
    Using index 'Name'
    Having Indexes:
    Name 1553 entries, 17 pages, 1543 values
      which has 1 column, fixed
    ID 1553 entries, 4 pages, 1553 values
      which has 1 column, fixed, clustered and/or counter
- End inputs to Query -
01) Scan table 'tb_bauteile_Basis'
    Using index 'Name'

次に、からインデックスを削除しましNameた。新しいクエリプランは次のとおりです。

- Inputs to Query -
Table 'tb_bauteile_Basis'
    Using index 'PrimaryKey'
    Having Indexes:
    PrimaryKey 1553 entries, 4 pages, 1553 values
      which has 1 column, fixed, unique, clustered and/or counter, primary-key, no-nulls
    Plauskomponente 1553 entries, 4 pages, 3 values
      which has 1 column, fixed
    Name 1553 entries, 17 pages, 1543 values
      which has 1 column, fixed
    ID 1553 entries, 4 pages, 1553 values
      which has 1 column, fixed, clustered and/or counter
- End inputs to Query -
01) Scan table 'tb_bauteile_Basis'
    Using index 'PrimaryKey'

これらの2つのクエリプランをどのように解釈する必要がありますか？

つまり、2番目のショープランでは、のインデックスを作成する必要がPlauskomponente,Name,IDあり、これら3つのフィールドの複合インデックスを作成する必要がありますか？複合インデックスを作成する必要があるかどうかをどのように判断できますか？

そして、なぜPlauskommponente最初のショープランに表示されないのですか？

4

2 に答える 2

2

2番目のショープランでは、次のことを意味します。Plauskomponente、Name、IDのインデックスを配置する必要がありますか？これらの3つのフィールドから複合インデックスを作成する必要がありますか？コンポジットインデックスを作成する必要があることをどのように見つけることができますか？

これらの名前は、クエリプランを考案するときにJetが分析する情報を表示するShowPlanセクションに表示されます。これらの3つのフィールドのインデックスは、個別のインデックスまたは3つすべてに基づく単一の複合インデックスのいずれかであり、その特定のクエリには役立ちません。また、実際にインデックスを追加すると、他の操作が遅くなります...行を追加または削除したり、インデックス付きフィールドの値を編集したりする場合、dbエンジンはテーブルと複合インデックスに変更を書き込む必要があります。

インデックス作成の最適化には注意が必要です。インデックスはSELECTを高速化できますが、INSERT、DELETE、およびUPDATE操作を低速化します。アプリケーションに適したバランスを見つける必要があります。Accessのこれに比較的慣れていない場合は、メニューのデータベースツールセクションからパフォーマンスアナライザウィザードを試してください。それが提供する提案を調べてください。多くの場合、これらの提案にはインデックスが含まれます。提案されたインデックスを追加し、それらが全体的なパフォーマンスを低下させたり改善しなかったりした場合は、後でそれらを削除できます。

Plauskommponenteが最初のショープランに表示されないのはなぜですか？

私を殴る。クエリプランナーはすでにNamesインデックスを見つけていると思うので、他のインデックスを探すのは無意味だと考えました。

しかし、それは別の重要なポイントをもたらします。テーブルには1,553行が含まれていますが、Plauskomponenteには3つの異なる値しか含まれていません。このように変動性が低いため、Plauskomponenteのインデックスは、Plauskomponenteに基づくWHERE句を持つクエリのプランではおそらく使用されません。@Namphibianはコメントで理由に触れました。インデックスを読み取って基準に一致する行を見つけてから、一致する行を読み取ることは、単にインデックスを無視してテーブルからすべての行を読み取るよりもコストがかかると見なされる可能性があります。

最後に、ShowPlan情報セクションに記載されている統計に注目してください。これらの統計は、データベースを圧縮すると更新されます。したがって、圧縮は、クエリプランナーがクエリプランを最適化する方法を決定するときに使用する最新の情報を提供するのに役立ちます。

于 2012-04-17T15:15:58.013 に答える
0

クエリはテーブル全体を読み取っています。where句はありません。最適化できる可能性は低いです。できることは、必要な列を選択することだけです。これにより、返されるデータの量が減ります。where句がないため、インデックスを追加してもクエリは高速化されません。where句を追加し、where句で使用されるフィールドにインデックスを付けると、クエリを最適化できる可能性があります。

于 2012-04-17T11:21:58.770 に答える