Oracle Optimizer不太喜欢使用索引

问题描述 投票：2回答：3

我正在加入一个表自己，虽然我希望这个操作使用索引，但它似乎没有。表上有100万条记录（MY_TABLE），我运行的查询正在大约1万条记录上执行。（因此它低于整个表的％1。）

测试用例：

explain plan for
SELECT *
  FROM SCHM.MY_TABLE A1, SCHM.MY_TABLE A2
 WHERE     (A1.K_ID = '123abc')
       AND A1.HDT = A2.HDT
       AND A2.C_DATE BETWEEN A1.SYSDATE - 0.0004 
                           AND A1.SYSDATE + 0.0004 
       AND A1.GKID = A2.GKID;


Plan hash value: 1210306805

----------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                  |     3 |    81 |    28   (0)| 00:00:01 |
|*  1 |  FILTER                               |                  |       |       |            |          |
|*  2 |   HASH JOIN                           |                  |     3 |    81 |    28   (0)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| MY_TABLE          |     3 |    45 |     7   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | IX_MY_TABLE_C_DATE |     3 |       |     4   (0)| 00:00:01 |
|   5 |    TABLE ACCESS BY INDEX ROWID BATCHED| MY_TABLE          |    17 |   204 |    21   (0)| 00:00:01 |
|*  6 |     INDEX RANGE SCAN                  | IX_MY_TABLE_K_ID |    17 |       |     4   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(SYSDATE@!+0.00004>=SYSDATE@!-0.00004)
   2 - access("A1"."HDT"="A2"."HDT" AND 
              "A1"."GKID"="A2"."GKID")
   4 - access("A2"."C_DATE">=SYSDATE@!-0.00004 AND 
              "A2"."C_DATE"<=SYSDATE@!+0.00004)
   6 - access("A1"."K_ID"=U'123abc')

在上面的语句中，可以看出使用了C_DATE上的索引。

但是，在下面的语句中，不使用C_DATE上的索引。因此，查询运行速度非常慢。

真实案例：

explain plan for
SELECT *
  FROM SCHM.MY_TABLE A1, SCHM.MY_TABLE A2
 WHERE     (A1.K_ID = '123abc')
       AND A1.HDT = A2.HDT
       AND A2.C_DATE BETWEEN A1.C_DATE - 0.0004 
                           AND A1.C_DATE + 0.0004 
       AND A1.GKID = A2.GKID;


Plan hash value: 1063167343

----------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                  |  4187K|   998M|  6549K  (1)| 00:04:16 |
|*  1 |  HASH JOIN                            |                  |  4187K|   998M|  6549K  (1)| 00:04:16 |
|   2 |   JOIN FILTER CREATE                  | :BF0000          |    17 |  2125 |    21   (0)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| MY_TABLE          |    17 |  2125 |    21   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | IX_MY_TABLE_K_ID |    17 |       |     4   (0)| 00:00:01 |
|   5 |   JOIN FILTER USE                     | :BF0000          |  1429M|   166G|  6546K  (1)| 00:04:16 |
|*  6 |    TABLE ACCESS STORAGE FULL          | MY_TABLE          |  1429M|   166G|  6546K  (1)| 00:04:16 |
----------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access(A1.HDT=A2.HDT AND 
              A1.GKID=A2.GKID)
       filter(A2.C_DATE>=INTERNAL_FUNCTION(A1.C_DATE)-0.00004 AND 
              A2.C_DATE<=INTERNAL_FUNCTION(A1.C_DATE)+0.00004)
   4 - access(A1.K_ID=U'123abc')
   6 - storage(SYS_OP_BLOOM_FILTER(:BF0000,A2.HDT,A2.HDT))
       filter(SYS_OP_BLOOM_FILTER(:BF0000,A2.HDT,A2.HDT))

如果我使用提示qazxsw poi，一切都很好，使用索引，查询运行速度很快我想要。

真实案例中的查询无法更改，因为它是由应用程序创建的。

/*+index(A2,IX_MY_TABLE_C_DATE )*/

为了使用索引在实际案例中查询，我需要更改什么？

sql oracle indexing query-performance
3个回答
2
投票

好吧，第二个查询较慢，因为它与第一个查询完全不同。它在表之间有一个额外的连接：

Index Information:
K_ID, not unique, position 1
HDT, not unique, position 1
C_DATE, not unique, position 1
ID Unique and Primary Key, position 1

而且在一百万行上这会造成损失。

第一个查询没有此连接条件，并且两个表都是：

  • 首先过滤。使用索引很快：只有3行和17行。
  • 加入他们第二。连接3行和17行不需要任何时间。

第二个查询需要执行：

  • 首先是一个巨大的（哈希）连接，它可能返回100K +行。
  • 稍后过滤。

这比较慢。

我建议添加以下索引，然后再试一次：

AND A2.C_DATE BETWEEN A1.C_DATE - 0.0004 
                  AND A1.C_DATE + 0.0004
2
投票

您的自联接中有三个连接条件（HDT，GKID，C_DATE）和一个非连接条件（K_ID）。所以对我来说，如果DBMS以匹配K_ID的记录开始，然后查找所有匹配的其他记录，这似乎很自然。

对于这种情况，我建议以下索引：

create index ix_1 (k_id);
create index ix_2 (hdt, gkid, c_date);

如果每个k_id只有很少的记录，我确信Oracle将使用这些索引。如果有很多，Oracle仍然可以使用第二个进行散列连接。

1
投票

只需添加，只要你有一个案例

  1. 有一个慢的SQL，
  2. 已经确定了一个可以加快速度的提示
  3. 无法更改SQL，因为源不可用

那么这是SQL Plan Baselines的完美案例。这些允许您在不触及SQL语句本身的情况下针对现有SQL锁定“良好”计划。

描述SPM的整个系列在下面的链接中，但是对于“第4部分”的概述将详细介绍您想要实现的内容。

create index idx1 on my_table(k_id, hdt, gkid, c_date); create index idx2 on my_table(hdt, gkid, c_date); https://blogs.oracle.com/optimizer/sql-plan-management-part-1-of-4-creating-sql-plan-baselines https://blogs.oracle.com/optimizer/sql-plan-management-part-2-of-4-spm-aware-optimizer https://blogs.oracle.com/optimizer/sql-plan-management-part-3-of-4:-evolving-sql-plan-baselines

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.