我已经阅读了一些有关MySQL中的临时表的信息，但是当涉及到一般的数据库，尤其是MySQL时，我是一个公认的新手。我已经看过一些示例以及有关如何创建临时表的MySQL文档，但是我试图确定临时表如何使我的应用程序受益，我想第二是我会遇到什么样的问题。当然，每种情况都不同，但是我想我正在寻找的是关于该主题的一些一般性建议。

我做了一些谷歌搜索，但没有找到我真正想要的主题。如果我们有任何经验，我很想听听。

谢谢，
马特

解决方案

过去我需要创建评估数据时就使用过它们。那是在MySQL中进行视图和子选择之前，我通常现在使用那些需要临时表的视图。我唯一使用它们的时间是评估的数据是否花了很长时间才能创建。

当我们要执行一个相当复杂的SELECT，然后对该表执行一堆查询时，临时表通常很有价值。

我们可以执行以下操作：

CREATE TEMPORARY TABLE myTopCustomers
   SELECT customers.*,count(*) num from customers join purchases using(customerID)
   join items using(itemID) GROUP BY customers.ID HAVING num > 10;

然后针对myTopCustomers进行一堆查询，而不必对每个查询进行购买和商品的联接。然后，当应用程序不再需要数据库句柄时，就不需要进行清理。

几乎总是会看到用于派生表的临时表创建起来很昂贵。

使用临时表的最佳位置是当我们需要从多个表中提取一堆数据，对这些数据进行一些处理，然后将所有内容组合到一个结果集中时。

在MS SQL中，由于与游标相关联的速度和资源影响，也应尽可能使用临时表代替游标。

我尚未在MySQL中完成这些操作，但已在其他数据库(Oracle，SQL Server等)上完成了这些操作。

在其他任务中，临时表为我们提供了一种创建专门构建的可查询(和从存储过程返回的)数据集的方法。假设我们有几张表格-我们可以使用一个临时表格将这些表格汇总为干净的总计(或者其他数学运算)，然后将该临时表格与架构中的其他表格结合起来以进行最终输出。 (在我的一个项目中，此示例正在计算给定销售相关员工每周，每两周，每月等必须进行多少次预定呼叫)

我还经常将它们用作"倾斜"数据的一种方法-将列转换为行等。它们对于高级数据处理很有用-但仅在需要时才使用它们。 (我的黄金法则一如既往地适用：如果我们不知道为什么使用x，并且不知道x的工作原理，那么我们可能不应该使用它。)

通常，我通常在需要复杂数据处理的存储过程中最多使用它们。我想举一个具体的例子，但是我的将是T-SQL(而不是MySQL的更标准的SQL)，而且它们都是我无法共享的客户端/生产代码。我敢肯定，SO上的其他人会接手并提供一些真实的示例代码；这只是为了了解域临时表要解决的问题的要点。

首先，我的工作是报告一份免责声明，因此我得到的查询要比任何普通开发人员都要复杂得多。如果我们正在编写一个简单的CRUD(创建读取更新删除)应用程序(这将是大多数Web应用程序)，那么我们确实不想编写复杂的查询，并且如果需要创建临时表，可能会做错事情。

就是说，出于多种目的，我在Postgres中使用了临时表，并且大多数表都将转换为MySQL。我用它们将复杂的查询分解为一系列易于理解的部分。我通过一系列查询生成复杂的报告来使用它们，以便保持一致性，然后可以将其中一些查询卸载到我在多个地方使用的模块中，可以确保不同的报告彼此一致。 (并确保如果我需要修复某些问题，只需要修复一次即可。)而且，很少有人故意使用它们来强制执行特定的查询计划。 (除非我们真的了解自己在做什么，否则请勿尝试此操作！)

所以我认为临时表很棒。但是，对我们而言，理解数据库通常具有两种风格非常重要。第一个优化用于抽出大量小额交易，第二个优化用于抽出少量复杂的报表。这两种类型需要进行不同的调整，并且在事务数据库上运行的复杂报表存在阻塞事务的风险(因此使网页无法快速返回)。因此，我们通常不想避免同时使用两个数据库。

我的猜测是我们正在编写需要事务数据库的Web应用程序。在这种情况下，我们不应使用临时表。并且，如果确实需要从事务数据生成的复杂报告，建议的最佳实践是进行定期(例如每日)备份，将其还原到另一台计算机上，然后针对该计算机运行报告。

如果我们不熟悉数据库，Joe Kelko的一些好书将回顾ANSI SQL的最佳实践。 SQL For Smarties将详细描述临时表的使用，索引的影响，where子句等。这是一本非常详尽的参考书。