0

我对 oracle SQL 语句有一个奇怪的性能问题。该语句或多或少是一个巨大的子选择/内部连接语句，因此我只能在这里发布它的结构。它看起来像这样：

SELECT "A".COL1, [...] FROM "A"
INNER JOIN ( .. massive amount of subselects and joins ... )
WHERE [...]

该语句的执行速度非常快（约 30 秒）。为了进一步提高速度，我决定按时间限制选择：

SELECT "A".COL1, [...] FROM "A"
INNER JOIN ( .. massive amount of subselects and joins ... )
WHERE "A".TIMESTAMP > ... AND [...]

这产生了完全相反的效果。语句执行时间现在超过 600 秒 (!!)。

解释计划现在设置完全不同（正如我所说，只是因为一个单一的更多限制 - 限制有一个完整的索引）。之前它是一个“正常”的组合，包括连接、索引限制和快速全扫描。之后它被成千上万的嵌套循环完全搞砸了。

我知道这很难从外面说出来，但是有什么一般提示可以在一开始就导致这些嵌套循环吗？EXPLAIN 计划开始 (!!) 之前：“正常” Hash 的组合加入限制等等。深度总是 < 10

| Id  | Operation                                             | Name               | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                                      |                    |   461 |   286K|  1672   (5)| 00:00:11 |
|   1 |  SORT GROUP BY                                        |                    |   461 |   286K|  1672   (5)| 00:00:11 |
|*  2 |   HASH JOIN                                           |                    |   461 |   286K|  1671   (5)| 00:00:11 |
|   3 |    VIEW                                               | index$_join$_016   |  2822 | 93126 |    21   (5)| 00:00:01 |
|*  4 |     HASH JOIN                                         |                    |       |       |            |          |
|*  5 |      INDEX RANGE SCAN                                 | HRP1000~0          |  2822 | 93126 |     5   (0)| 00:00:01 |
|*  6 |      INDEX FAST FULL SCAN                             | HRP1000~1          |  2822 | 93126 |    19   (0)| 00:00:01 |
|*  7 |    HASH JOIN                                          |                    |   459 |   270K|  1649   (5)| 00:00:11 |
|*  8 |     HASH JOIN                                         |                    |   459 |   259K|  1609   (5)| 00:00:10 |
|*  9 |      TABLE ACCESS FULL                                | BBP_PDORG          | 14463 |   607K|    39   (0)| 00:00:01 |
|* 10 |      HASH JOIN                                        |                    |  1939 |  1013K|  1569   (5)| 00:00:10 |
|* 11 |       HASH JOIN RIGHT OUTER                           |                    |   691 |   335K|  1548   (5)| 00:00:10 |
|  12 |        VIEW                                           |                    |  1572 | 47160 |   148   (5)| 00:00:01 |
|  13 |         HASH GROUP BY                                 |                    |  1572 |   411K|   147   (5)| 00:00:01 |

之后 - 大量嵌套循环。深度 > 20

| Id  | Operation                                                    | Name               | Rows  | Bytes | Cost (%CPU)| Time
----------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                                             |                    |     1 |  1392 |   329   (6)| 00:00:03
|   1 |  SORT GROUP BY                                               |                    |     1 |  1392 |   328   (5)| 00:00:03
|   2 |   NESTED LOOPS                                               |                    |     1 |  1392 |   327   (5)| 00:00:03
|   3 |    NESTED LOOPS                                              |                    |     1 |  1371 |   327   (5)| 00:00:03
|   4 |     NESTED LOOPS                                             |                    |     1 |  1333 |   327   (5)| 00:00:03
|   5 |      NESTED LOOPS                                            |                    |     1 |  1312 |   327   (5)| 00:00:03
|   6 |       NESTED LOOPS                                           |                    |     1 |  1274 |   326   (5)| 00:00:03
|   7 |        NESTED LOOPS                                          |                    |     1 |  1235 |   326   (5)| 00:00:03
|   8 |         NESTED LOOPS                                         |                    |     1 |  1196 |   326   (5)| 00:00:03
|   9 |          NESTED LOOPS                                        |                    |     1 |  1175 |   326   (5)| 00:00:03
|  10 |           NESTED LOOPS                                       |                    |     1 |  1137 |   325   (5)| 00:00:03
|  11 |            NESTED LOOPS                                      |                    |     1 |  1116 |   325   (5)| 00:00:03
|  12 |             NESTED LOOPS                                     |                    |     1 |  1078 |   325   (5)| 00:00:03
|  13 |              NESTED LOOPS                                    |                    |     1 |  1061 |   325   (5)| 00:00:03
|  14 |               NESTED LOOPS                                   |                    |     1 |  1010 |   324   (5)| 00:00:03
|  15 |                NESTED LOOPS                                  |                    |     1 |   988 |   324   (5)| 00:00:03
|* 16 |                 HASH JOIN                                    |                    |     1 |   953 |   324   (5)| 00:00:03
|  17 |                  NESTED LOOPS                                |                    |       |       |            |
|  18 |                   NESTED LOOPS                               |                    |     1 |   898 |   284   (6)| 00:00:02
|  19 |                    NESTED LOOPS                              |                    |     1 |   853 |   284   (6)| 00:00:02
|* 20 |                     HASH JOIN                                |                    |     1 |   823 |   284   (6)| 00:00:02
|  21 |                      NESTED LOOPS                            |                    |     1 |   780 |   236   (6)| 00:00:02
|  22 |                       NESTED LOOPS                           |                    |     1 |   741 |   236   (6)| 00:00:02
|  23 |                        NESTED LOOPS                          |                    |     1 |   701 |   235   (6)| 00:00:02
|  24 |                         NESTED LOOPS                         |                    |     1 |   639 |   235   (6)| 00:00:02
|  25 |                          NESTED LOOPS                        |                    |     1 |   609 |   235   (6)| 00:00:02
|  26 |                           NESTED LOOPS                       |                    |     1 |   576 |   235   (6)| 00:00:02
|  27 |                            NESTED LOOPS                      |                    |     1 |   533 |   234   (6)| 00:00:02
|  28 |                             NESTED LOOPS                     |                    |     1 |   495 |   234   (6)| 00:00:02
4

2 回答 2

0

以下可能是时间增加的原因：-

  1. INDEX:- 如果假设您之前的查询的 where 条件是 (where col1 ='' and col2 = '') 并且您在 col1,col2 上创建了一个复合索引，那么您的查询将利用索引并进行索引快速全扫描等. 如果你的时间戳过滤器没有被索引，那么你的查询就不再使用索引，而是进行全表扫描（增加时间）

  2. 时间戳列放置：- 由于时间戳放置错误，您的解释计划的深度会增加。正如我们所知，我们的查询从最后开始运行，即假设您的查询的 where 条件是这样的（其中 col1 = '' 和 col2 = '' 和 col3 = ''），所以您的数据将首先根据 col3 然后 col2 然后科尔1。因此，如果在您的子查询中添加了此时间戳条件。每次您的查询都会根据时间戳进行过滤，因为我们知道每次处理外部查询时都会运行子查询。

所以我建议如果你在子查询中使用时间戳然后修改相同。建议：- 分析查询或派生查询比子查询运行得更快，因为子查询的限制是，对于外部查询的每一行，内部查询都会被处理

于 2013-10-29T10:31:00.563 回答
0

优化器可能认为这A.TIMESTAMP > ...会大大减少命中次数，以至于对少量行使用嵌套循环比执行大型连接更便宜。

根据提供的稀缺信息，很难确定确切原因以及是否有简单的方法来纠正问题。

当您添加索引（或索引列上的条件）时，执行计划会发生巨大变化，您应该不会感到惊讶。我有点惊讶它选择更改计划进行>比较。限制是一个固定值（即优化器是否知道）并且它是否接近表中的最大值（如表统计信息中记录的那样）？

关于时间戳有一个警告，那就是最高值的统计数据很快就会过时。假设您的统计数据是 24 小时前的，并且您正在查找过去 24 小时内的日期。优化器将使用统计信息并预测查询将导致 0 次命中。所以它将从检查索引开始。

实际上，您在过去 24 小时内输入了许多新记录。一整天的新记录...

直接设置优化器的一种方法是提供截止日期作为参数（并在适用时预编译问题），这样优化器就不会被愚弄认为它会获得 0 次点击。

于 2013-10-29T11:25:16.437 回答