强制 Oracle 使用主键索引而不使用提示答案

【问题标题】：Forcing Oracle to use Primary Key Index without using Hints强制 Oracle 使用主键索引而不使用提示
【发布时间】：2012-01-29 12:05:21
【问题描述】：

我们有一个应用程序可以生成一些临时表，然后处理数据。我真的无法控制应用程序创建此内容的方式以及所涉及的后续查询。我们注意到的是，Oracle 使用全表扫描而不是使用作为表主键的索引。如果它使用主键索引，则该过程将运行得更快。

由于我无法控制应用程序生成的选择查询，我无法使用提示并强制 Oracle 使用主键索引。是否有任何其他设置可以更改以强制 Oracle 对临时表使用主键索引？

【问题讨论】：

您能否再添加一个具有自动递增序列的列并将该列设置为主键列
我更喜欢 MSSQL，但强制查询的唯一方法是通过提示。从您的措辞中不清楚您是否可以控制临时表的创建。您确定正在创建 PK 吗？如果存在 PK / FK 关系，那么它们是否被声明（在 MSSQL 中，查询优化器使用它）？在合乎逻辑的情况下，我从来没有遇到过不使用 PK 的查询。
@BalamBalam 我无法控制临时表的创建。但是，我们确实检查以确保正在创建 PK。我不知道为什么查询优化器不使用它，这是一个奇怪的问题，因为我无法向查询添加任何提示。
@Emmanuel N 不幸的是，我无法控制新表的创建，所以我无法添加另一列
他们是否加入了您可以控制的表？确保您可以控制的表已正确索引并且没有碎片。确保他们正在建立统计数据。您可以使用您可以控制的表来构建统计信息。我怀疑这会解决任何问题，但它可能不会破坏任何东西。

标签： oracle optimization indexing primary-key

【解决方案1】：

查询不使用索引的两个最常见原因是：

执行全表扫描更快。
统计数据不佳。

如果您的查询选择了所有表或进行连接而没有在 where 子句中提及主键等，那么进行全扫描可能会更快。如果没有查询和索引，最好还有一个解释计划，就无法确定。

不过，我建议您要求您的 DBA 重新收集 - 我希望，如果不是第一次收集的话 - 表格上的统计信息。使用dbms_stats.gather_table_stats，估计百分比为25%+。

如果每次运行应用程序时都重新创建表，则尝试在创建和生成主键后收集统计信息。如果它们每次都被截断并重新填充，请让您的 DBA 重建它们和 PK，然后收集统计信息，因为这可能会显着增加查询运行时间。

由于无法控制任何事情，我看不出如何以任何其他方式改善查询时间。

【讨论】：

With no control over anything I don't see how you can improve the query time any other way. -> 这个。也许最好同时收集整个架构统计信息。
@Sathya，是的，我想是的。我正在使用某些表格回答一个查询，但是如果统计信息收集得不好，那么值得在任何地方都这样做。
为模式中的其他表收集统计信息应用程序创建临时表，使用它们并在进程完成时删除它们，因此收集统计信息可能是一个问题。那么我想没有办法改善查询时间。
@Eosphorus，有很多方法可以改进查询，但它们都需要你对正在发生的事情有某种“权力”。如果无论如何要在应用程序中间添加收集统计信息，那么我肯定会尝试它；它不应该伤害任何东西，并且可能会大大改善它。
@Eosphorus 您可能还需要考虑提高动态采样级别：docs.oracle.com/cd/E11882_01/server.112/e16638/stats.htm#i42991

【解决方案2】：

通过利用 SQL 配置文件，您可以在不更改 SQL 的情况下使用提示。将提示包装到对特定 SQL ID 生效的 SQL 配置文件中。

我了解您无法控制 SQL，我有许多应用程序遇到相同的限制。在按照 Ben 的帖子检查查询结构和统计信息后，您已经证明使用索引的提示会提高性能，为什么不尝试手动创建 SQL 配置文件。

Christian Antognini 有一篇很棒的论文here 关于 SQL 配置文件并手动创建它们。该论文提到手动创建 SQL 配置文件没有记录。我同意无证，但这并不一定意味着不受支持。我想说那里几乎没有文档，但是如果您想证明 Oracle 允许手动创建，请检查 API 或查看 SQLT 实用程序目录中的 coe_xfr_sql_profile.sql 文件。

我还发布了一份关于如何快速手动创建 SQL 配置文件 here 的备忘单。

【讨论】：

非常感谢。这篇文章非常有帮助。我会调查这个