sql - 每次都维护一个单独的计数表与运行计数查询更好吗？

Question

我正在构建一个社交应用程序，它具有类似于 Twitter 的关注/关注概念。

从性能的角度来查找关注者数量和关注用户数，是否单独维护一个表来统计计数更好？还是每次都做一个计数查询？

更新:

同样，我有一种调查功能，人们可以在其中投票，人们只能投赞成票或反对票。现在我将选票存储在一个单独的表中。我需要在我的主页上显示没有参与者的调查列表，没有是的，没有的。

类似于 stackoverflow 主页(其中显示投票数、答案和观看次数)。

Answer 1

与大多数事情一样，这取决于访问模式，即您的系统将被使用的方式。如果更新将是您的主要瓶颈，那么您不应该通过维护计数器来增加开销。另一方面，如果在访问数据时准备好计数会为您节省大量时间，或者每次都计数是不可行的，那么您应该预先计算它。

作为一般准则，不要添加表，例如您建议的单独计数表，这些表在您实际测量性能成为问题之前纯粹用于性能优化。有一个单独的计数表会破坏规范化(就像任何一种缓存一样，因为数据现在在两个地方复制)并且会使代码更加复杂，因此不应该仅仅因为可能需要计数就这样做。

(总而言之，一些数据库支持materialized views / materialized queries，可以让你轻松地在后台透明地进行这种缓存。那些物化表由数据库更新，所以程序代码不必担心它并且此外，根据查询优化器的复杂程度，可用于透明地优化查询。)

更新:否/是投票问题有点不同，因为主要目的只是跟踪计数，不一定是整个信息(即谁投了赞成票)。因此，一个有效的实现可能是只跟踪累积的赞成票和反对票的数量。但是，您存储的信息越多(即谁投了赞成票，而不仅仅是投了多少票)，如果您选择这样做，您可以用它做的事情就越多(例如，在 Stackoverflow 中，我总是可以删除我的赞成票——如果你没有追踪谁投票了)。我再次建议不要过早聚合，在这种情况下，因为您会丢失某些信息。