Oracle：检索ORA_ROWSCN会大大降低大表上的查询速度（没有where子句）

我想使用伪列ORA_ROWSCN以增量方式向数据目标提供数据，但我面临一些我不理解的问题。检索此伪列会减慢我的查询速度。。很多

我正在处理一个大数据库。我在示例中使用的两个表分别是1352885行和12701489行

让我们看看这两个不同的查询：

案例A:

select
  ta.id,
  tb.id
from table_a ta
left join table_b tb
on ta.tb_id = tb.id
fetch first 1 row only;

这个查询已经很长了（持续时间在这里只是一个指示）

• 第1轮：10秒
• 第二轮：2秒

案例B: 将2个ora_rowscn字段添加到select

• 第1轮：20秒
• 第二轮：20秒

所以第二个查询比第一个查询长。但在我的实际查询中，包含许多连接，结果甚至是最差的，有和没有ora_rowscn检索的查询之间的比率高达50

使此策略无法使用：-(

欢迎提供有关此行为的任何信息或提示

我要说的是，我在网上搜索，没有找到任何与这个约束相关的东西。我想在这里问这个问题会很有趣

---

谢谢！

查询的第一个版本可以在大部分工作中使用索引，第二个版本必须访问该表才能获取系统更改号

我假设列

ID

是主键并被索引。

tbu ID

可能是外键，通常也被索引。这意味着第一次查询中使用的每一列都是索引的一部分。Oracle可以从索引中检索所有必要的数据，甚至不需要访问任何表。

ORA_ROWSCN

没有索引，需要查找表。我假设索引比表小得多，因此一旦需要访问表，就有很多数据要读取。ORA_ROWSCN没有什么特别之处，任何未索引的值都会出现同样的问题

创建示例架构 收集执行计划 比较执行计划 案例A仅对表_B使用索引扫描

Plan hash value: 218395200

-----------------------------------------------
| Id  | Operation              | Name         |
-----------------------------------------------
|   0 | SELECT STATEMENT       |              |
|   1 |  VIEW                  |              |
|   2 |   WINDOW NOSORT STOPKEY|              |
|   3 |    NESTED LOOPS OUTER  |              |
|   4 |     TABLE ACCESS FULL  | TABLE_A      |
|   5 |     INDEX UNIQUE SCAN  | SYS_C0017639 |
-----------------------------------------------

案例B仍然可以使用表_B上的索引，但现在还必须从表本身读取

Plan hash value: 259330422

-------------------------------------------------------
| Id  | Operation                      | Name         |
-------------------------------------------------------
|   0 | SELECT STATEMENT               |              |
|   1 |  VIEW                          |              |
|   2 |   WINDOW NOSORT STOPKEY        |              |
|   3 |    NESTED LOOPS OUTER          |              |
|   4 |     TABLE ACCESS FULL          | TABLE_A      |
|   5 |     TABLE ACCESS BY INDEX ROWID| TABLE_B      |
|   6 |      INDEX UNIQUE SCAN         | SYS_C0017639 |
-------------------------------------------------------

---

请运行

EXPLAIN PLAN select….查询的其余部分A….

然后运行

select*FROM table（dbms\u xplan.display）

，然后复制上一次查询的结果并将其追加（作为文本-而不是位图！！！！）对于问题。第二个查询也是这样。这些是分析SQL查询的性能问题所必需的基本步骤-生成和分析它们的计划。哦，对不起！我错了，计划不一样…是的，案例A使用ans索引。非常感谢。这就是重点。我认为计划是一样的，但我错了。它使用indice在案例A中为s，在案例B中为表访问。因此，我必须改变解决问题的方式，因为ORA_ROWSCN无法编制索引：-(

explain plan for
select
  ta.id,
  tb.id
from table_a ta
left join table_b tb
on ta.tb_id = tb.id
fetch first 1 row only;

select * from table(dbms_xplan.display(format => 'basic'));


explain plan for
select
  ta.id,
  tb.id,
  ta.ora_rowscn versa, 
  tb.ora_rowscn versb
from table_a ta
left join table_b tb
on ta.tb_id = tb.id
fetch first 1 row only;

select * from table(dbms_xplan.display(format => 'basic'));

Plan hash value: 218395200

-----------------------------------------------
| Id  | Operation              | Name         |
-----------------------------------------------
|   0 | SELECT STATEMENT       |              |
|   1 |  VIEW                  |              |
|   2 |   WINDOW NOSORT STOPKEY|              |
|   3 |    NESTED LOOPS OUTER  |              |
|   4 |     TABLE ACCESS FULL  | TABLE_A      |
|   5 |     INDEX UNIQUE SCAN  | SYS_C0017639 |
-----------------------------------------------

Plan hash value: 259330422

-------------------------------------------------------
| Id  | Operation                      | Name         |
-------------------------------------------------------
|   0 | SELECT STATEMENT               |              |
|   1 |  VIEW                          |              |
|   2 |   WINDOW NOSORT STOPKEY        |              |
|   3 |    NESTED LOOPS OUTER          |              |
|   4 |     TABLE ACCESS FULL          | TABLE_A      |
|   5 |     TABLE ACCESS BY INDEX ROWID| TABLE_B      |
|   6 |      INDEX UNIQUE SCAN         | SYS_C0017639 |
-------------------------------------------------------