我已经阅读了一些关于 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 执行一堆查询，而不必在每个查询中对购买和商品进行连接。然后，当您的应用程序不再需要数据库句柄时，无需进行清理。
您几乎总是会看到用于派生表的临时表，这些表的创建成本很高。
【讨论】：
首先是免责声明 - 我的工作是报告，所以我最终会遇到比任何普通开发人员都复杂得多的查询。如果您正在编写一个简单的 CRUD（创建读取更新删除）应用程序（这将是大多数 Web 应用程序），那么您真的不想编写复杂的查询，如果您需要创建临时表，您可能做错了。
也就是说，我在 Postgres 中出于多种目的使用临时表，并且大多数会转换为 MySQL。我使用它们将复杂的查询分解为一系列可单独理解的部分。我使用它们是为了保持一致性——通过一系列查询生成复杂的报告，然后我可以将其中一些查询卸载到我在多个地方使用的模块中，我可以确保不同的报告彼此一致。 （并确保如果我需要修复某些东西，我只需要修复一次。）而且，我很少故意使用它们来强制执行特定的查询计划。 （除非你真的明白你在做什么，否则不要尝试这个！）
所以我认为临时表很棒。但话虽如此，非常您必须了解数据库通常有两种风格。第一个针对抽取大量小交易进行了优化，另一个针对抽取少量复杂报告进行了优化。这两种类型需要进行不同的调整，并且在事务数据库上运行的复杂报表存在阻塞事务的风险（因此导致网页无法快速返回）。因此，您通常不想避免同时使用一个数据库。
我的猜测是您正在编写一个需要事务数据库的 Web 应用程序。在这种情况下，您不应该使用临时表。如果您确实需要从交易数据生成复杂报告，建议的最佳做法是定期（例如每天）备份，在另一台机器上恢复它们，然后针对该机器运行报告。
【讨论】：
使用临时表的最佳位置是当您需要从多个表中提取一堆数据，对这些数据进行一些处理，然后将所有内容合并到一个结果集时。
在 MS SQL 中，由于与游标相关的速度和资源影响，还应尽可能使用临时表代替游标。
【讨论】：
如果您是数据库新手，Joe Kelko 的一些好书可以回顾 ANSI SQL 的最佳实践。 SQL For Smarties 会详细介绍临时表的使用、索引的影响、where 子句等。这是一本很好的参考书，内容很详细。
【讨论】：
我过去在需要创建评估数据时使用过它们。那是在 MySQL 中的视图和子选择之前，我现在通常使用那些我需要临时表的地方。我可能会使用它们的唯一情况是评估数据需要很长时间才能创建。
【讨论】：
我没有在 MySQL 中做过，但我在其他数据库（Oracle、SQL Server 等）上做过。
在其他任务中，临时表为您提供了一种方法来创建专门构建的可查询（并且可以从存储过程中返回）数据集。假设您有几个数字表——您可以使用一个临时表将这些数字汇总到漂亮、干净的总计（或其他数学），然后将该临时表连接到您的架构中的其他表以获得最终输出。 （在我的一个项目中，这方面的一个例子是计算给定销售相关员工每周、每两周、每月等必须拨打多少预定电话。）
我还经常将它们用作“倾斜”数据的一种方式——将列转换为行等。它们适用于高级数据处理——但仅在需要时才使用它们。 （我的黄金法则一如既往地适用：如果你不知道为什么要使用 x，也不知道 x 是如何工作的，那么你可能不应该使用它。）
一般来说，我最常在需要复杂数据处理的存储过程中使用它们。我很想举一个具体的例子，但我的会是 T-SQL（而不是 MySQL 更标准的 SQL），而且它们都是我无法共享的客户端/生产代码。我相信这里的其他人会拿起并提供一些真正的示例代码；这只是为了帮助您了解域临时表解决的问题的要点。
【讨论】：