PK / indexを使用せずにレコードを挿入し、後でthmeを作成する方が、PK / Indexを使用して挿入するよりも高速であることを確認します。
注ここで
のポイントは、インデックス作成に時間がかかることではありませんが(明らかです)、総コスト(インデックスなしで挿入+インデックスを作成)は(インデックス付きで挿入)よりも高くなります。インデックスなしで挿入し、後でインデックスを作成するように教えられたからです。
DELLLatitudeコアi72.8GHz8GメモリおよびSSDHDD上のWindows764ビットOracle11G R264
ビット
PK / Indexなしでレコードを挿入し、挿入後にレコードを作成する方が、PK / Indexありで挿入するよりも高速であると教えられました。
ただし、PK / Indexを使用した100万件のレコード挿入は、実際には後でPK / Indexを作成するよりも高速で、以下の実験では約4.5秒対6秒でした。レコードを300万(999000-> 2999000)に増やすことにより、結果は同じでした。
フラッシュするSQL:
ALTER SYSTEM CHECKPOINT;
ALTER SYSTEM FLUSH SHARED_POOL;
ALTER SYSTEM FLUSH BUFFER_CACHE;
「PK /インデックスなしで挿入+ PK /インデックス作成を後で挿入する」の方が「PK /インデックスを使用して挿入する」よりも速いというのは本当ですか?
実験でミスをしたり、いくつかの条件を逃したりしましたか?
TRUNCATE TABLE TBL2;
ALTER TABLE TBL2 DROP CONSTRAINT PK_TBL2_COL1 CASCADE;
ALTER TABLE TBL2 ADD CONSTRAINT PK_TBL2_COL1 PRIMARY KEY(COL1) ;
SET timing ON
INSERT INTO TBL2
SELECT i+j, rpad(TO_CHAR(i+j),100,'A')
FROM (
WITH DATA2(j) AS (
SELECT 0 j FROM DUAL
UNION ALL
SELECT j+1000 FROM DATA2 WHERE j < 999000
)
SELECT j FROM DATA2
),
(
WITH DATA1(i) AS (
SELECT 1 i FROM DUAL
UNION ALL
SELECT i+1 FROM DATA1 WHERE i < 1000
)
SELECT i FROM DATA1
);
commit;
1,000,000 rows inserted.
Elapsed: 00:00:04.328 <----- Insert records with PK/Index
TRUNCATE TABLE TBL2;
ALTER TABLE &TBL_NAME DROP CONSTRAINT PK_TBL2_COL1 CASCADE;
SET TIMING ON
INSERT INTO TBL2
SELECT i+j, rpad(TO_CHAR(i+j),100,'A')
FROM (
WITH DATA2(j) AS (
SELECT 0 j FROM DUAL
UNION ALL
SELECT j+1000 FROM DATA2 WHERE j < 999000
)
SELECT j FROM DATA2
),
(
WITH DATA1(i) AS (
SELECT 1 i FROM DUAL
UNION ALL
SELECT i+1 FROM DATA1 WHERE i < 1000
)
SELECT i FROM DATA1
);
commit;
ALTER TABLE TBL2 ADD CONSTRAINT PK_TBL2_COL1 PRIMARY KEY(COL1) ;
1,000,000 rows inserted.
Elapsed: 00:00:03.454 <---- Insert without PK/Index
table TBL2 altered.
Elapsed: 00:00:02.544 <---- Create PK/Index
CREATE TABLE TBL2 (
"COL1" NUMBER,
"COL2" VARCHAR2(100 BYTE),
CONSTRAINT "PK_TBL2_COL1" PRIMARY KEY ("COL1")
) TABLESPACE "TBS_BIG" ;
1つ以上のインデックスを変更する必要がなく、制約チェックも実行する必要がない場合は、テーブルを変更する方が速いのは事実ですが、それらのインデックスを追加する必要がある場合も、ほとんど関係ありません。システムの一部だけでなく、実行したいシステムへの完全な変更を検討する必要があります。
明らかに、すでに数百万の行が含まれているテーブルに1つの行を追加する場合、インデックスを削除して再構築するのはばかげています。
ただし、数百万行を追加する完全に空のテーブルがある場合でも、インデックス作成を後回しにするのに時間がかかる場合があります。
この理由は、このような挿入はダイレクトパスメカニズムで実行するのが最適であり、インデックスが設定されたテーブルにダイレクトパス挿入を使用すると、インデックスの作成に必要なデータ(データとROWID)を含む一時セグメントが作成されるためです。 )。これらの一時セグメントがロードしたばかりのテーブルよりもはるかに小さい場合は、スキャンとインデックスの作成も高速になります。
別の方法として、テーブルに5つのインデックスがある場合は、インデックスを作成するために、ロード後に5回の全表スキャンを実行します。
明らかに、ここには巨大な灰色の領域が含まれていますが、次の点でうまく機能しています。
編集:
さらなる考慮事項-インデックスが削除されている間にバックアップを実行します。緊急復旧後、システムを復旧するためにビジネスに息を吹き込んだときに、すべてのインデックスが適切に配置されていることを確認するスクリプトが必要になります。
また、一括読み込み中にインデックスを維持しないと絶対に決定した場合は、インデックスを削除しないでください。代わりに無効にしてください。これにより、インデックスの存在と定義のメタデータが保持され、より単純な再構築プロセスが可能になります。テーブルを切り捨てて誤ってインデックスを再度有効にしないように注意してください。無効にされたインデックスが再び有効になります。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加