下面是我的查询，我使用四个联接来访问来自三个不同表的数据，现在搜索1000条记录大约需要5.5秒，但当我将其放大到100000条时，似乎需要无限长的时间，（最后一次取消是在7小时。）
有人知道我做错了什么吗？或者可以做些什么来加快查询速度？
这个查询很可能最终必须运行才能返回数百万条记录，为了测试查询，我只将其限制在100000条，即使是这么少量，它似乎也会失败。
记录我在甲骨文8
CREATE TABLE co_tenancyind_batch01 AS
SELECT /*+ CHOOSE */ ou_num,
x_addr_relat,
x_mastership_flag,
x_ten_3rd_party_source
FROM s_org_ext,
s_con_addr,
s_per_org_unit,
s_contact
WHERE s_org_ext.row_id = s_con_addr.accnt_id
AND s_org_ext.row_id = s_per_org_unit.ou_id
AND s_per_org_unit.per_id = s_contact.row_id
AND x_addr_relat IS NOT NULL
AND rownum < 100000
用图片说明计划：https://i.stack.imgur.com/SDmN2.jpg（易于阅读）
如果要运行数百万行，那么基于100000行的测试就没有意义了。优化器知道，当它通过使用嵌套循环联接具有stopkey时，它可以更快地满足查询。
当你为一个非常大的数据集运行它时，你可能需要一个不同的计划，最有可能的是散列连接。覆盖索引可能会有所帮助，但我们无法判断，因为所选列缺少列别名，这些别名告诉我们它们来自哪个表。您最有可能遇到大散列联接的内存问题，这可以通过散列分区来改善，但Siebel人员不可能做到这一点——您必须使用手动内存管理和监视v$sql_workarea来查看您真正需要多少。
（顺便说一句，讨厌视觉解释计划）。
首先，您能确保S_CONTACT表上有一个索引并已启用吗？
如果是这样，请尝试使用/*+CHOOSE*/hint的select语句，然后再查看解释计划，看看优化器模式是否仍然是规则的。我相信基于成本的优化器会在这个查询中得到更好的结果。
如果仍然是规则，请尝试更新数据库统计信息，然后重试。您可以为此使用DBMS_STATS包，如果我没有错的话，它是在8i版本中引入的。你在用8i吗？
最后，我不知道记录的数字，表之间的基数。如果我知道这个设计的话，我可能会更有帮助。
您的数据集，查看上一次执行计划时，看起来非常庞大，您可以限制对基表的访问，而不是限制返回行的数量，如下所示：
CREATE TABLE co_tenancyind_batch01 AS
SELECT /*+ CHOOSE */ ou_num,
x_addr_relat,
x_mastership_flag,
x_ten_3rd_party_source
FROM s_org_ext,
s_con_addr,
s_per_org_unit,
(select * from s_contact where rownum <= 100000) cont
WHERE s_org_ext.row_id = s_con_addr.accnt_id
AND s_org_ext.row_id = s_per_org_unit.ou_id
AND s_per_org_unit.per_id = cont.row_id
AND x_addr_relat IS NOT NULL
应该改进，但不要太快。