使用临时表是否明智?

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

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

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

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

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

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

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

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

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

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

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

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

相关文章

在正式开始之前,我们先来看下 MySQL 服务器的配置和版本号信...
> [合辑地址:MySQL全面瓦解](https://www.cnblogs.c...
物理服务机的CPU、内存、存储设备、连接数等资源有限,某个时...
1 回顾 上一节我们详细讲解了如何对数据库进行分区操作,包括...
navicat查看某个表的所有字段的详细信息 navicat设计表只能一...
文章浏览阅读4.3k次。转载请把头部出处链接和尾部二维码一起...