Oracle 数据库中的两个相似表 - 不同的执行计划

Question

我们在数据库中有两个相似的表。除了 table_name 外，这些表具有相同的 DDL，它们也具有相似的索引列，重新收集两个表的统计信息并执行索引重建。表之间的唯一区别是表中的数据（行数、行值、不同值等）。当我们在表上运行我们的选择查询时，它们都会产生不同的解释计划。使用 INDEX RANGE SCAN（1 秒）的速度更快。几天前使用 INDEX FULL SCAN（1-3 分钟内完成）较慢的情况在这张表上不是这种情况。每天在两个表上都发生多次插入、更新和删除。我们可以研究哪些内容来重现该问题？

下面是没有问题的表的解释计划

-----------------------------------------------------------------------------------------------------------------------
| Id  | Operation                              | Name                         | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                       |                              |     1 |  5833 |     4   (0)| 00:00:01 |
|*  1 |  COUNT STOPKEY                         |                              |       |       |            |          |
|   2 |   VIEW                                 |                              |     1 |  5833 |     4   (0)| 00:00:01 |
|*  3 |    SORT ORDER BY STOPKEY               |                              |     1 |  1173 |     4   (0)| 00:00:01 |
|*  4 |     TABLE ACCESS BY INDEX ROWID BATCHED| SABA_MESSAGES                |     1 |  1173 |     4   (0)| 00:00:01 |
|*  5 |      INDEX RANGE SCAN                  | SABA_IDX_MESSAGES_PROCESS_ID |     1 |       |     3   (0)| 00:00:01 |

解释有问题的表的计划（进行索引全扫描）

---------------------------------------------------------------------------------------------
| Id  | Operation                     | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |             |     1 |  5833 |    23   (0)| 00:00:01 |
|*  1 |  COUNT STOPKEY                |             |       |       |            |          |
|   2 |   VIEW                        |             |     2 | 11666 |    23   (0)| 00:00:01 |
|*  3 |    TABLE ACCESS BY INDEX ROWID| MESSAGES    |   108K|   104M|    23   (0)| 00:00:01 |
|   4 |     INDEX FULL SCAN           | MESSAGES_PK |   124 |       |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------


There are 3 existing index for these tables 
MESSAGES_PK ON MESSAGES ("ID") = Primary Key
IDX_MESSAGES_PROCESS_ID ON MESSAGES" ("PROCESS_ID")
IDX_MESSAGES_MESSAGE_TYPE" ON MESSAGES"("MESSAGE_TYPE") 

TABLE_NAME             NUM_ROWS     BLOCKS AVG_ROW_LEN STA
-------------------- ---------- ---------- ----------- ---
MESSAGES                6705777     989842        1014 NO
SABA_MESSAGES           2721695     472871        1173 NO

Answer 1

我们无法为您解决该问题，但可以为您提供一些指导。查看 TABLE ACCESS 行上的 Rows 列。最上面的一个需要 1 行。底部预计有 108,000 行。这至少是它选择全扫描的原因之一（这得益于更高效的“分散”多块读取而不是顺序单块读取）。要确定原因，我们需要查看统计数据和谓词。顶部的#4 和#5 旁边有一个星号，底部的#3 旁边也有一个星号。下面应该有针对这些步骤编号的谓词脚注。该谓词信息与来自 d​​ba_tab_statistics 和 dba_tab_col_statistics 的统计数据相结合通常能够确定基数（ROWS 列）估计值的原因。然后是索引——了解每种情况下的索引列列表是什么也很重要。需要的索引是否可见，是否处于可用状态也很关键。如果您正在使用绑定变量，请查看您的 sqlid 的 v$sql_bind_capture 并获取绑定的值，以查看绑定查看可能如何影响它。确保绑定的数据类型与您希望它使用的索引的前导列的数据类型相匹配。

归根结底，如果您无法从结构上或统计上解决问题，那就是提示的作用。只需提示查询执行您希望它执行的操作并完成它：

SELECT /*+ INDEX(messages,IDX_MESSAGES_PROCESS_ID) */ -- or whatever the index is
  FROM messages
 WHERE ...

当然，这只有在索引可用、可见，甚至远程可用于您的谓词时才有效，唯一的问题是基数计算错误。

Answer 2

@Paul W - 两个表的索引相同，索引有效且可用。我们也在查询中使用相同的文字值。我将分享更详细的信息。我们已经查看了 dba_tab_statistics 和 dba_tab_col_statistics 但仍无法确定问题所在。我们正在检查表的数据分布和数据偏斜度，但想不出如何进一步重现该问题。

正在使用的查询： SELECT a.* FROM (SELECT t0.message_type AS MESSAGE_TYPE_1, t0.message AS MESSAGE_2, t0.received_time AS RECEIVED_TIME_3, t0.process_start_time AS PROCESS_START_TIME_4, t0.process_id AS PROCESS_ID_5, t0.process_stop_time AS PROCESS_STOP_TIME_6, t0.error AS ERROR_7, t0.formatted_message AS FORMATTED_MESSAGE_8, t0.barcode AS BARCODE_9, t0.cavity_label AS CAVITY_LABEL_10, t0.order_number AS ORDER_NUMBER_11, t0.id AS ID_12, t0.version AS VERSION_13, t0.is_inactive AS IS_INACTIVE_14 FROM gta.messages t0 WHERE t0.process_id = -1 AND ((t0.is_inactive = 0)) ORDER BY t0.id ASC) a WHERE ROWNUM <= 1;

---

|编号 |操作 |名称 |行 |字节 |成本 (%CPU)|时间 |

| 0 |选择语句 | | 1 | 5833 | 23 (0) | 00:00:01 | |* 1 |计数主键 | | | | | | | 2 |查看 | | 2 | 11666 | 23 (0) | 00:00:01 | |* 3 |按索引 ROWID 访问表 |留言 | 108K| 104M| 23 (0) | 00:00:01 | | 4 |索引全扫描 |消息_PK | 124 | | 3 (0)| 00:00:01 |

`谓词信息（由操作id标识）：

1 - 过滤器（ROWNUM<=1） 3 - 过滤器（“T0”。“PROCESS_ID”=（-1）和“T0”。“IS_INACTIVE”=0）`

统计数据

      8  recursive calls
      0  db block gets
1857241  consistent gets
 975801  physical reads
      0  redo size
   1469  bytes sent via SQL*Net to client
    544  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      0  sorts (memory)
      0  sorts (disk)
      0  rows processed