为 Oracle 设置优化器索引成本调整参数的正确方法是什么。作为一名开发人员，我观察到随着此参数的降低，性能得到了巨大的提升。常见查询从 2 秒减少到 200 毫秒。网上有很多警告称，降低此值会导致数据库出现严重问题，但没有详细说明会引发哪些问题。
我目前只看到了好处，应用程序性能大大提高，没有看到坏处。我需要更好地了解调整这些参数可能产生的负面影响。
答案1
不建议更改这些参数的原因是它们对优化器具有数据库范围的影响 - 因此当您更改它以调整特定查询时，它可能会对许多其他查询产生影响。因此，在生产中更改它而不仔细测试整个应用程序是危险的。
然而：
- 在开发/测试环境中设置它，并在生产中保持相同的值可能是可以接受的（曾经是 OLTP 系统中的常见做法）。但是，你能确定你的应用程序将在专用数据库中运行吗？并且永远不会合并到具有一组默认参数的另一个数据库中？
- 这些参数之所以有用，是因为 Oracle 使用了一些关于 I/O 与 CPU 相对成本的启发式方法，而对于你的情况，这些启发式方法不够好，因此 Oracle 选择了次优执行计划。修复启发式方法的推荐方法是让 Oracle 收集系统统计对于您的数据库机器 - CPU 的速度有多快，在常规系统负载期间从 I/O 系统获取单个块/多个块需要多长时间等等。请参阅 Oracle 文档。
如果您想同时使用系统统计数据和优化器参数，请谷歌搜索，Jonathan Lewis 写过相关内容（抱歉，该网站不允许我发布多个链接）
我希望这能有所帮助
答案2
在生产环境中不应更改该参数。主要用途是强制更改计划，以验证不同执行计划的性能。基本上，您建议优化器，数据库中的所有索引都比其他访问路径更便宜。对于某些 SQL 来说，这可能是正确的，但对于其他 SQL 来说，这可能不正确。
一旦您有了一个好的性能计划，您就应该理解为什么优化器不使用它并尝试修复（即没有可用的新鲜/准确的静态数据->收集新鲜的、更准确的统计数据）。
希望这有帮助，Stefano
答案3
对于最常见的数据库类型 OLTP 系统来说，这两个参数的默认值非常糟糕。它们会导致更多全表扫描和错误查询。通常，您需要在上线之前设置这些参数。您可以在测试阶段进行设置。
如果在上线后更改它们，则可能会更改已调整为错误设置的其他查询。听起来您对数据库调整了解不多，因为您提到了响应时间而不是查询计划。您不应该触碰这些参数。
大多数 DBA 不了解修复和设计之间的概念差异。上线后，您就开始修复，这时您需要小心更改这些参数。上线前，您处于设计和开发阶段。这时您可以像这样调整参数。
顺便说一句，这些参数是一个很好的起点（请注意，在投入生产之前，并且只有当您知道自己在做什么时！）
optimizer_index_cost_adj=10 优化器缓存=90
这是针对 OLTP 的。对于批处理，您要开始使用的设置非常不同。我稍微修改了一下这些设置，但这些设置在 OLTP 上 99% 的时间里都能给我带来最佳的整体效果。但是，在投入生产后我不会再修改它们。如果它们不好，我会保留它们并调整查询。