我的应用程序如何从临时表中受益？

我一直在阅读关于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.我用它们将复杂的查询分解成一系列可以理解的部分.我使用它们来保持一致性 - 通过一系列查询生成一个复杂的报告,然后我可以将其中的一些查询卸载到我在多个地方使用的模块中,我可以确保不同的报告彼此一致.(并确保如果我需要修复某些内容,我只需要修复一次.)而且,很少,我故意使用它们强制执行特定的查询计划.(除非你真的明白自己在做什么,否则不要试试!)

所以我认为临时表很棒.但话虽如此,了解数据库通常有两种形式非常重要.第一个是针对大量小型交易进行优化的,另一个针对抽出少量复杂报告进行了优化.这两种类型需要进行不同的调整,并且在事务数据库上运行的复杂报表会存在阻塞事务的风险(因此会使网页无法快速返回).因此,您通常不希望避免将两个数据库用于这两个目的.

My guess is that you're writing a web application that needs a transactional database. In that case, you shouldn't use temp tables. And if you do need complex reports generated from your transactional data, a recommended best practice is to take regular (eg daily) backups, restore them on another machine, then run reports against that machine.