1

次の構造を持つOracle 11g テーブル (と呼ばれるitems) に格納されている複数の階層メニューがあります。

  • menu: 項目が属するメニューの ID。
  • id: メニュー項目の ID。メニュー内ではユニークですが、テーブル内ではユニークではありません。
  • name: メニュー項目の名前。
  • parent:idメニュー項目の親 (常に同じメニューにあります)。

テーブルには約 100.000 行が含まれています。次のクエリを使用して、すべてのメニュー項目とそれに対応するルート項目のリストを生成します。

SELECT
    name,
    CONNECT_BY_ROOT name AS root
FROM
    items
CONNECT BY
    PRIOR id = parent AND
    PRIOR menu = menu
START WITH
    parent IS NULL

(1 つのメニューに複数のルートが存在する可能性があるため、connect by なしで通常の結合を使用することはできません。)

このクエリを最適化するには、どのインデックスを作成する必要がありますか? id一意性を確保するためにとの複合インデックスを既に持っていますがmenu、それ以上必要ですか?

また、適切なインデックスを作成した場合、このクエリの複雑さはどのくらいになるでしょうか? アイテムの総数、メニューごとの数、メニューの深さに関連していますか?

編集:これは次の出力ですEXPLAIN PLAN:

ID | PARENT_ID | OPERATION        | OPTIONS                      | OPTIMIZER
---+-----------+------------------+------------------------------+------------------
0  |           | SELECT STATEMENT |                              | SELECT STATEMENT
1  | 0         | CONNECT BY       | NO FILTERING WITH START-WITH | CONNECT BY
2  | 1         | TABLE ACCESS     | FULL                         | TABLE ACCESS

ただし、まだ完全なデータセットを持っていないため、これは 100 アイテムの小さなデータセットのみです。スペース上の理由から、いくつかの列を除外しました。出力から他に何か必要な場合はお知らせください。

4

1 に答える 1

1

エントリ ポイントはparent IS NULL、デフォルトではインデックスをまったく使用しないため、完全なテーブル スキャンが実行されます。この式に基づいた関数ベースのインデックスは、データ ボリュームが大きい場合に役立つ場合があります。その後、再帰は親とメニューを使用してテーブルにアクセスするため、親とメニューの結合インデックスが適切な場合があります。実行時間は、言及したすべての基準の関数である必要がありますが、適切なインデックスを作成すると、それらの影響が大幅に軽減される可能性があります。

于 2015-10-28T11:07:10.670 に答える