Oracle 调优优化器索引成本调整和优化器索引缓存

不建议更改此参数的原因是它们对优化器具有 db 范围的影响 - 因此，当您更改它以调整特定查询时，它可能会对许多其他查询产生一些影响。因此，在没有仔细测试整个应用程序的情况下在生产环境中更改它是危险的。

然而：

1. 在开发/测试环境中设置它，并在生产中保持相同的值可能是可以接受的（过去是 OLTP 系统中的常见做法）。但是，您能确定您的应用程序将在专用数据库中运行吗？并且永远不会使用一组默认参数合并到另一个数据库中？
2. 这些参数有帮助，因为 Oracle 使用了一些关于 I/O 与 CPU 的相对成本的启发式方法，而在您的情况下，启发式方法还不够好，因此 Oracle 选择了次优的执行计划。修复启发式的推荐方法是让 Oracle 为您的 db 机器收集系统统计信息- CPU 有多快，在常规系统负载期间从 I/O 系统获取单块/多块需要多长时间等。请参阅 Oracle文档。

如果您想同时使用系统统计信息和优化器参数，请在 google 上搜索，Jonathan Lewis 写道（抱歉，该网站不允许我发布多个链接）

我希望这会有所帮助

不应在生产环境中更改该参数。主要用途是强制更改计划，以验证不同执行计划的性能。基本上，您建议优化器使用数据库中的所有索引比使用其他访问路径更便宜。这对于某些 sql 可能是正确的，而对于其他的可能是错误的。

一旦你有一个好的性能计划，你应该理解为什么优化器不使用它并尝试修复（即没有新的/准确的静态数据可用 -> 收集新的、更准确的统计数据）。

希望这会有所帮助，斯特凡诺

这两个参数的默认值对于最常见的数据库类型 OLTP 系统来说非常糟糕。它们会导致更多的全表扫描和错误查询。通常，您希望在上线之前设置这些参数。您在测试阶段执行此操作。

如果您在上线后更改它们，那么您可能会更改已调整为错误设置的其他查询。听起来您对数据库调优不太了解，因为您提到了响应时间而不是查询计划。您不应该触摸这些参数。

大多数 DBA 不了解修复和设计之间的概念差异。上线后，您正在修复，这时您需要小心更改这些参数。在您入住之前，您正处于设计和开发阶段。那就是当你像这样调整参数的时候。

顺便说一句，从这些参数开始的好地方（在你去生产之前注意，只有你知道你在做什么！）

optimizer_index_cost_adj=10 优化器缓存=90

这适用于 OLTP。对于批处理，您要开始的设置非常不同。我对这些进行了一些修改，但这些设置在 OLTP 上 99% 的时间都为我提供了最佳的整体结果。但是，在我们投入生产后，我不会碰它们。如果它们不好，我会让它们变得不好并调整查询。