SQL中的临时表

Question

我需要知道将复杂查询分解为多个部分并创建最终删除的临时表是否是标准做法。在OLAP应用程序中，它不应该是一个大问题，但在OLTP中，因为速度很重要，是否可以避免？。

Answer 1

你问题中的关键词是“分解”。通常不鼓励临时表和其他策略，并且发现导致整体性能降低。优化器完全能够使用中间表，如果它们对于最快速地获得答案很有用。很少有人可以通过用自己的策略强制来帮助优化器。

同样的事情是建议使用哪些索引。

当你看到这种情况时，几乎总有一个人有更多工作需要改进他们的查询语句。

Answer 2

对于由DBMS进行了优化的简单查询，临时表通常是一个坏主意，因为它们会带来开销。

但有时您的DBMS将很难优化复杂查询。那时你至少有5个选择：

1. 更改架构或索引，以使优化程序更容易选择更好的查询计划
2. 调整您的SQL以让DBMS选择您想要的索引，连接策略等，并在DBMS的优化器中解决已知和未知的错误。
3. 使用“提示”让DBMS选择您想要的索引，加入策略等。
4. 获取您想要的计划并使用“已保存的计划”强制DBMS使用它。
5. 使用临时表（或表变量等）将复杂查询分解为更简单的中间查询

关于哪个选项最适合任何特定查询，没有严格的规则。我已经使用了上述所有策略。当我不拥有架构时，我倾向于选择临时表方法，所以我不能改变它，当我不想依赖于提示或查询调优或保存计划时（通常因为我不想要让我自己接触后面制作的底层架构的变化。

请记住，使用临时表来分解查询会使您每次都获得次优性能。但它通常可以预测是次优的。使用临时表的最坏情况并不像DBMS为单个大型查询选择错误计划时那么糟糕。这种情况经常发生，尤其是面对底层架构，DBMS版本更改，开发与生产差异等方面的变化等。

就我个人而言，我发现如果查询达到一定程度的复杂性，我必须向后弯腰以使DBMS做我想做的事情，如果我觉得应用程序的可维护性存在风险，那么我如果我无法更改模式或索引，通常会使用分解和临时表。

当然，从理论上讲，您不应该在OLTP数据库上运行昂贵，复杂的查询，但实际上大多数应用程序从来都不是“纯粹的”OLTP--在任何应用程序中始终存在一些复杂的，难以优化的查询OLTP项目。

Answer 3

我在OLTP处理期间唯一一次使用临时表的时候是我正在处理需要分析/加入的一批数据，并最终对其进行数据更改操作（插入/更新/删除）。我将使用临时表来表示速度，但更重要的是，b）因为正常的选择/更新或选择/删除逻辑太复杂或者无法在一个事务语句中完成。

例如，查找满足某些条件的100k用户，并将其插入存档表中，然后将其删除。

我不建议在大多数情况下使用临时表来进行正常的select语句。通过正确的索引，更好的sql join /提示和/或更改数据结构以匹配数据访问路径，您几乎总能获得更好的性能。

Answer 4

IN oltp系统如果处理是在线系统的一部分（即不是批处理），那么我不记得曾经使用临时表。使用某种程序逻辑通常是要走的路 - 例如Oracle中的PL / Sql等等。

在OLAP中临时表非常常见，通常将数据加载到表中，对其进行转换并将结果保存在另一个表中，并且根据处理有多个转换步骤。

我甚至会说，如果你有一个oltp系统，你需要使用一个临时表，然后一些东西是不正确的，修改你的设计，或使用程序逻辑。在OLAP中，临时表非常常见。

HTH