使用临时表是否明智？

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

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

价格存储在另一个表中,称为价格.有多种价格类别,具体取决于每个访客(客户)适用的折扣级别.有时会有活动,这意味着每种产品都有特殊的价格.特价存储在称为特价的表中.

>制作将表绑定在一起的临时表是否不好？

它仅具有必要的信息,并且当然将被缓存.

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

这样,就很容易知道特定产品是否真的有价格,而不必每次都要列出或展示产品时都要遍历完整的价格或特价表.

>临时表是Web应用程序的常识,还是设计不好？

解决方法:

您应该像处理其他任何性能问题一样处理它：确定所需的性能,然后重复在实验室中的生产级硬件上进行测试.不要做不必要的优化.

您应该分析您的应用程序,并发现它执行的查询太多还是查询本身很慢；大多数网络应用程序运行缓慢的情况都是由进行过多查询(以我的经验)引起的,尽管查询非常简单.

通常,最佳的工程解决方案是重组数据库(在某些情况下会进行非规范化),以使普通读取用例需要较少的查询.缓存也可能会有所帮助,但重构通常是最好的,因此您需要较少的查询.

本质上,如果您计划进行比写更多的读取,则可以增加写路径上的工作量,以减少读路径上的工作量.

标签：performance,database-design,scalability,temp-tables,mysql
来源： https://codeday.me/bug/20191210/2099196.html