Oracle 11G – 插入时索引的机能影响

目标

验证插入没有PK /索引的记录加上其后建设的记录是否真的比插入PK /索引更快.

留意
这里的要点不是索引必要更多时刻(很明明),但总本钱(不带索引的插入建设索引)高于(行使索引插入).由于我被辅导插入没有索引而且稍后建设索引由于它应该更快.

情形

DELL Latitude焦点i7 2.8GHz 8G内存和Windows上的Windows 7 64位SSD硬盘
Oracle 11G R2 64位

配景

我被辅导插入没有PK /索引的记录并在插入后建设它们比插入PK /索引更快.

然而,行使PK / Index的100万个记录插入现实上比建设PK / Index更快,约莫4.5秒对6秒,下面的尝试.通过将记录增进到300万(999000 – > 2999000),功效是沟通的.

前提

>表DDL如下.数据和数据的一个bigfile表空间
指数.
(测试了一个单独的索引表空间,具有沟通的功效和较差的整体perforemace)
>每次运行前冲洗缓冲液/阀芯.
>每次运行尝试3次并确保功效
很相似.

要革新的SQL：

ALTER SYSTEM CHECKPOINT;
ALTER SYSTEM FLUSH SHARED_POOL;
ALTER SYSTEM FLUSH BUFFER_CACHE;

题

“插入PK /索引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

插入没有PK /索引的记录并在之后建设它们

TRUNCATE TABLE TBL2;
ALTER TABLE &TBL_NAME DROP CONSTRAINT PK_TBL2_COL1 CASCADE;

SET TIMING ON
INSERT INTO TBL2
SELECT i+j,(
  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 rows inserted.
Elapsed: 00:00:03.454 <---- Insert without PK/Index

table TBL2 altered.
Elapsed: 00:00:02.544 <---- Create PK/Index

表DDL

CREATE TABLE TBL2 (
    "COL1" NUMBER,"COL2" VARCHAR2(100 BYTE),CONSTRAINT "PK_TBL2_COL1" PRIMARY KEY ("COL1")
) TABLESPACE "TBS_BIG" ;

办理要领

显然,假如要将一行添加到已包括数百万行的表中,那么删除和重建索引将是愚笨的.

可是,纵然你有一个完全空的表,你将要添加数百万行,但耽误索引到之后如故会更慢.

缘故起因是这样的插入最好用直接路径机制执行,当你行使直接路径插入到带有索引的表中时,会构建包括构建索引所需数据的姑且段(数据加rowid) ).假如这些姑且段比您刚加载的表小得多,那么它们扫描和构建索引的速率也会更快.

另一种要领是,假如表上有五个索引,则在加载它之后要举办五次全表扫描以构建索引.

显然这里涉及庞大的灰色地区,但做得很好：

>质疑势力巨子和一样平常履历法例,以及
>运行现实测试以确定您本身案例中的究竟.

编辑：

进一步的思量身分 – 在删除索引时运行备份.此刻,在紧张规复之后,您必需有一个脚原来验证全部索引是否到位,当您让营业喘不外气来让体系从头启动时.

另外,假如您绝对抉择在批量加载时代不维护索引,请不要删除索引 – 而是禁用它们.这样可以保存索引存在和界说的元数据,并应承更简朴的重建进程.请留意,不要通过截断表不测从头启用索引,由于这将再次启用禁用的索引.

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!