1

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

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)|   
------------------------------------------------------------------------------------
4

4 回答 4

3

“问题是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 语句将失败。万一你有一个更大的问题，你需要思考。

“但是 [MYTAB2] 包含的行数非常不稳定......基本上一些行被添加到表中，然后一些行被删除并且过程继续”

在这种情况下，拥有任何固定统计数据都是有帮助的。一个更好的主意是强制优化器在运行时动态生成统计信息。

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

如果您启用了动态采样，则删除表的统计信息然后将其锁定将强制数据库在每次将表包含在查询中时为其生成统计信息。每当您运行该删除语句时，这应该会生成一个更好的执行计划，而不管 MYTAB2 在那一刻碰巧持有多少行。

了解更多。

于 2012-04-27T13:43:38.667 回答
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;
于 2012-04-27T11:32:00.757 回答
2

优化器认为MYTAB2大约有 437,000 行，因此您尝试删除表中大约 11.6% 的行。如果MYTAB2实际上只有 1,000 行，则意味着统计信息MYTAB2已过时。如果您在表上收集统计信息

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

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

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

于 2012-04-27T15:10:50.907 回答
1

Oracle 10.2 中的索引创建文档在这里。

你需要类似的东西：

create index index_name on table_name(column_name);
于 2012-04-27T11:26:08.510 回答