Question

我有这个查询，我想通过添加适当的索引来提高其性能。

DELETE FROM MYTAB1 WHERE MYID1 IN (SELECT MYID2 FROM MYTAB2);

我不熟悉索引的语法及其所需的设置类型。请提供相同的。这里的主要问题是MYTAB1有数百万条记录，因此查询需要花费大量时间。但是，MYTAB2只有1000条记录。 MYID1是MYTAB1的主要关键

我尝试过创建索引：

CREATE INDEX IDX_TAB1_ID1 ON MYTAB1(MYID1);

它对查询的性能没有太大影响。

我运行了解释计划并得到了这个：

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------   
| Id  | Operation             | Name          | Rows  | Bytes |TempSpc| Cost (%CPU)|
------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT      |               | 63977 |    11M|       | 62216   (2)|
|   1 |  DELETE               | MYTAB1        |       |       |       |            |
|   2 |   HASH JOIN RIGHT SEMI|               | 63977 |    11M|  7688K| 62216   (2)|
|   3 |    TABLE ACCESS FULL  | MYTAB2        |   437K|  2561K|       |  1189   (2)|
|   4 |    TABLE ACCESS FULL  | MYTAB1        |  3761K|   678M|       | 24718   (4)|   
------------------------------------------------------------------------------------

Answer 1

“事情是MYTAB2只有1000条记录！”

是但相关数据点是MYTAB1中有多少记录与这千条记录匹配？这个数字表示的整个表格的百分比是多少？这些记录在MYTAB1中的分布是什么？

如果您要删除MYTAB1中20％的行，索引只会使性能变差（如果优化器足够愚蠢以至于使用它）。如果您只删除了MYTAB1中0.1％的记录，但这些记录分布在表格中的每个块中，那么全表扫描也是更有效的选择。

调整中没有简单的解决方案。它总是取决于许多不同因素的相互作用。您希望多久运行一次此删除操作？您是否拥有企业版许可证和大量备用CPU容量？等等。

如果MYID1是MYTAB1的主键，那么该列上应该已经有一个UNIQUE索引。因此您无需创建新索引。

除非你是那些不打扰在你的表上应用完整性约束的地方之一。这是不好的做法。除了强制执行完整性的明显好处之外，约束还为优化器提供了有用的信息，从而产生了更好的执行计划。

无论如何，您现在发布的解释计划中明确了问题的根源。你说MYTAB2只有一千行，但优化器似乎认为它有四十三万七千行。所以，显然你需要在那张桌子上收集新的统计数据：

 exec dbms_state.gather_table_stats(ownname=>user, tabname=>'MYTAB2',estimate_percent=>100)

我想MYTAB1的统计数据是正确的，确实有370万行的数量？如果是这样，索引查找将是最高性能的选项。您需要检查该主键列上是否有唯一索引：

 select i.index_name, i.uniqueness
 from user_indexes i
     join user_ind_columns c
         on ( i.index_name =  c.index_name)
 where i.table_name = 'MYTAB1'
 and c.column_name = 'MYID1'

如果您没有索引，则需要创建索引：

 create unique index mytab1_uidx on mytab1(myid1)
 /

如果你有一个索引，但它不是唯一的那么你应该删除它并构建一个唯一的索引。

请注意，如果您错了并且该列不是主键 - 即它具有重复项 - 那么该CREATE INDEX语句将失败。在taht事件中你有一个更大的问题，你需要思考。

“但是[MYTAB2]包含的行数很多 volatile ...基本上有些行被添加到表中然后有些行删除并继续“

在这种情况下，任何固定的统计数据都很有用。更好的想法是强制优化器在运行时动态生成统计信息。

exec dbms_state.delete_table_stats(ownname=>user, tabname=>'MYTAB2')
exec dbms_state.lock_table_stats(ownname=>user, tabname=>'MYTAB2')

删除表的统计信息然后将其锁定将强制数据库在每次将其包含在查询中时为表生成统计信息，前提是已启用动态采样。无论何时运行该删除语句，这都应该生成一个更好的执行计划，无论MYTAB2当时碰巧有多少行。

Find out more.

Answer 2

这是一个经典问题。有时您最好创建一个包含要保存的行的新表，然后将new_table重命名为original_table。

概要：

create table new_table as 
select * from original_table 
where myid1 not in (select myid2 from mytab2)
;

drop table original_table;

rename new_table to original_table;

有关活动的更多详情：

Bulk Delete using CTAS Method
a.  Create table new_table with nologging
CREATE TABLE new_table NOLOGGING (….);
b.  Insert  /*+ APPEND */ into new_table select the records you want to keep from current_table.
c.  Create the indexes on the new_table with NOLOGGING  (*)
d.  Create constraints, grants etc.
e.  Drop current_table.
f.  Rename new_table to current.
g.  Backup the data.
(*) If the data left is so small or there are a lot of dependencies on the table (views, procedures, functions, etc) the following steps can be used instead of c-g above:
c.  Disable constraints on current_table.
d.  Truncate current_table;
e.  Make indexes unusable 
f.  Alter current_table NOLOGGING 
g.  Insert  /*+ APPEND */ into current_table 
select * from new_table; 
h.  commit;
i.  enable constraints
j.  Alter current_Table and indexes to LOGGING
k.  Backup the data
l.  drop table new_table;

Answer 3

优化器认为MYTAB2大约有437,000行，因此您尝试删除表中大约11.6％的行。如果MYTAB2实际上只有1,000行，则表示MYTAB2上的统计信息已过期。如果你收集表格的统计数据

BEGIN
  DBMS_STATS.GATHER_TABLE_STATS( <<owner of the table>>,
                                 'MYTAB2' );
END;

然后重新运行查询计划，计划是否会更改？查询运行得更快吗？

下一个问题是为什么优化器认为MYTAB2有这么多行。这是一个未声明为全局临时表的临时表吗？过去桌子是否大得多，但是你永久删除了437,000行437,000行？

Answer 4

Oracle 10.2中的索引创建文档为here。

您需要以下内容：

create index index_name on table_name(column_name);

在ORACLE上优化查询。试过索引

4 个答案: