使用临时表是否明智？

Question

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

数据库中对访问者可见的所有产品都附有价格：

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

• 制作一个将表绑定在一起的临时表是不是很糟糕？

它只有必要的信息，当然会被缓存。

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

通过这样做，很容易知道特定产品是否真的有价格，而不必在每次应该列出或展示产品时遍历完整的 prices 或 specials 表。

• 临时表是 Web 应用程序常见的东西还是只是糟糕的设计？

Answer 1

如果您仍然要缓存这些数据，它真的需要放在临时表中吗？只有在需要重建缓存时才会产生查询开销，因此可能甚至不需要临时表。

Answer 2

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

您应该分析您的应用并发现它是否执行了太多查询或者查询本身是否很慢；大多数网络应用程序运行缓慢的情况是由于执行了太多查询（根据我的经验），即使查询非常简单。

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

如果您打算做更多的阅读而不是写作，那么基本上您可以增加写入路径上的工作量以减少读取路径上的工作量。