で高速検索コレクション型を作成します。コレクション型の列
CREATE TYPE nums_list AS TABLE OF NUMBER;
は、コレクション型(ネストした表の列)の列を持つ表を作成します。テーブル内の
CREATE TABLE test1 (
num NUMBER,
tagged nums_list
)
NESTED TABLE tagged STORE AS mytest_tagged_table;
挿入1万行:
DECLARE
tagg_value nums_list := nums_list(3,4,5);
BEGIN
for i in 1..1000000 loop
if i = 600000 then
tagg_value := nums_list(7,8);
end if;
INSERT INTO test1
(num, tagged)
VALUES
(i, tagg_value);
end loop;
END;
次に、コレクションタイプの要素を検索するためにクエリを実行します。
select count(*) from test1 where 8 member of tagged;
このクエリは、実行時間が約7-8秒であり、ゆっくり実行されます。
質問:実行時間を短縮する方法を教えてください。インデックスかもしれない?しかし、どのようにネストしたテーブルの列のためのインデックスを使用する私は取得できません。
P.S.私は、カーソルを使用してPL/SQLブロック内のすべての行をチェックし、パイプライン化されたテーブル関数として結果を返すことを試みましたが、これは直接クエリよりも遅かったです。
あなたの例を書いたように、600,000以上のすべての行はリスト内の数字が8になると思います。つまり、クエリは400,000(1,000,000行のうち)を返します。ネストされたテーブルかどうかは、インデックスが役立つクエリのタイプではありません。この例ではあなたの意図は、クエリを満足する多くの行を持つことでしたか? –
@Matthew - 正確に400,001 rowsがこのクエリを返します。これは大きなデータですか? – RIKI
それはそれ自体が「大きな」ものではありません。テーブルの行の総数のうち大きな割合を占めています。そのような状況では、400,000回の索引検索ではなく、検索を実行するためにテーブル全体(すなわち、「全テーブルスキャン」)を読む方がより効率的である。1回のI/Oでフルスキャンで多くのテーブルブロックを読み取ることができますが、インデックスルックアップでは3〜4回の入出力が必要です。このような狭いテーブルでは、フル・テーブル・スキャンで100,000回のI/O(大まかな推測)を必要とする場合がありますが、索引付きのネストループ・ジョインは100万回以上のI/Oを必要とする場合があります。 –