使用临时表是否明智？

我们有一个用于products的mySQL数据库表。我们正在利用缓存层来减少数据库负载，但我们认为将缓存层中需要存储的实际数据最小化以进一步加速应用程序是一个好主意。使用临时表是否明智？

所有数据库中的产品，那就是游客必须重视他们的代价可见：

价格都存储在不同的表，称为prices。有多个价格类别取决于每个访问者（客户）适用的折扣级别。有时会有活动，这意味着每种产品都有特价。特殊价格存储在名为specials的表格中。

将临时表绑定在一起是不是很糟糕？

它只会有必要的信息，并且会被缓存。

-------------|-------------|------------ 
| productId | hasPrice | hasSpecial 
-------------|-------------|------------ 
    1   | 1   | 0 
    2   | 1   | 1

通过这样做，这将是超级容易知道具体的产品真正有价，而无需通过完整的prices或specials表中的产品应该上市交易或者提出每一次迭代。

临时表是Web应用程序常见的东西还是它只是坏的设计？

来源

2010-04-29 Industrial

不是一个坏的理想。 SQL Server具有群集索引视图，Oracle具有物化视图。他们实际上都在做你需要的东西。我很想知道MySQL是否有类似的结构，但我对此表示怀疑。 – 2010-04-29 12:32:01

嗨列文。感谢您的意见。 – Industrial 2010-04-29 13:10:50

您应该像处理其他任何性能问题一样处理它：确定需要多少性能，然后在您的实验室中对生产级硬件进行迭代测试。不要做不必要的优化。

你应该剖析你的应用并发现它是否做了太多的查询或查询本身很慢;即使查询非常简单，大多数Web应用程序缓慢的情况都是由于查询过多（以我的经验）。

通常情况下，最好的工程解决方案是重构数据库，在某些情况下可以非规范化，以使常见的读取用例需要更少的查询。缓存也可能会有所帮助，但重构需要更少的查询往往是最好的。

基本上，如果你打算做的比阅读更多的阅读，你可以增加写路径上的工作量以减少阅读路径的数量。

来源

2010-04-30 22:11:33 MarkR

如果你打算缓存这些数据，它真的需要在临时表中吗？当您需要重建缓存时，只会产生查询开销，因此临时表可能甚至不是必需的。

来源

2010-04-29 12:36:36

写入并保持缓存表更新的问题始终存在，但是再次，在加入与临时表的产品时，第一个查询会立即知道是否有兴趣查看价格/特价表为每个产品？ – Industrial 2010-04-29 12:47:00

@Industrial - 我想如果你有一张临时表，那么陈旧数据的问题可能会更糟，因为你的缓存不仅可能陈旧，而且临时表的内容也可能陈旧 - 尤其是如果更新的时间表他们没有适当的计时。 – 2010-04-29 12:53:33

嗯，是的。缓存失效一直是任何类型缓存的主要问题。它总是归结为缓存未命中和性能之间的折衷。您是否认为使用这种“临时”表格还是不好的数据库设计？ – Industrial 2010-04-29 13:01:09

使用临时表是否明智？

回答

相关问题