sql调优-具有多个联接

投资于Oracle这样的产品的原因之一是他们在引擎的优化器部分所做的开发工作。20多年来,它一直在不断改进,一般来说,如果对表和索引进行适当的统计,就很难在访问数据时正确地猜出它。

如果我将您的问题解释为在每次执行查询时通过构建临时表来提高实时数据查询的性能,那么我会说在大多数情况下不会。在其他情况下,不用构建临时表,而是用Oracle相对较新的with子句构建查询,该子句将动态处理具体化的数据子集 在那些优化器认为有意义的情况下。

如果您的问题是以物化视图、数据集市或数据仓库的方式对数据进行非规范化,那么是的,这可以极大地提高查询性能,代价是访问信息的当前状态(因为非规范化的表总是过时的)。这种改进通常是因为RDBMS引擎要对查询进行的物理访问工作较少,因为您已经完成了一次构建非规范化结构的工作。

如果查询不必绝对是最新的,这可能是可以接受的,例如统计报告查询通常可以忽略一天的数据。

您还可以在更新时使用触发器或通过存储过程执行更新来手动复制此效果。这种方法会导致非常脆弱的数据库,并且通常容易出错,因此我建议不要使用这种方法。

这在很大程度上取决于您的具体情况—这种更改可能会损害或提高性能。这方面没有一般的规则;有什么疑问 你

它可以提高性能,因为结果可能是一个更小的表,更容易查询和连接;查询优化器可能会自动执行此操作,但在某些情况下会出错。这是一种手动完成优化器工作的方法。

我认为这个“规则”的出现是因为当涉及到许多表时,数据库引擎的行为变得很难预测——每个额外的表都会增加执行查询的可能方法的数量。

从理论上讲,可以精确地跟踪Oracle优化器是如何做出决策的,并使用统计信息、提示和计划为其提供正确执行任务所需的信息。

临时表方法的缺点是,当资源发生变化时,无法对数据库进行“更好的”优化(即,DB服务器现在有8Gb内存,因此最快的方法是将所有表全部加载到内存中,但临时表方法已强制写回磁盘)。

对于那些不太理想的情况,您应该首先尝试在Oracle提供的系统中工作。我看到的大多数性能问题都是因为有人没有按逻辑方式进行操作,或者他们不知道现有的特性。例如,两次使用同一个表而不是使用分析。如果Oracle仍然在使用一个糟糕的解释计划,那么您应该考虑使用提示,或者像添加ROWNUM这样的技巧来阻止Oracle重新编写某些子查询。

如果一个临时表能帮上忙,Oracle会帮你做的。有时你可以在“解释计划”中看到像“系统温度…”这样的对象。