我正在构建一个社交应用程序，它具有类似于 twitter 的关注/关注概念。
从性能的角度来查找关注者和关注用户的数量，是否更好地为计数维护一个单独的表？还是每次都做一个计数查询？
更新：
同样，我有一个调查类功能，人们可以投票，人们只能投票赞成或反对。现在我将投票存储在一个单独的表格中。我需要在我的主页上显示没有参与者、没有是和没有的调查列表。
类似于 stackoverflow 主页（显示票数、答案和浏览量）。
【问题讨论】：
标签： sql database performance
与大多数情况一样，这取决于访问模式，即您的系统的使用方式。如果更新将是您的主要瓶颈，那么您不应该因为必须维护一个计数器而增加开销。另一方面，如果在访问准备好计数的数据时将为您节省大量时间，或者每次都计数不可行，那么您应该预先计算它。
作为一般准则，在您实际衡量性能是否存在问题之前，请勿添加纯粹用于性能优化的表（例如您建议的单独计数表）。拥有一个单独的计数表会破坏规范化（就像任何类型的缓存一样，因为数据现在在两个地方复制）并且会使代码更加复杂，因此不应该仅仅因为可能需要计数就这样做。
(话虽如此，有些数据库支持materialized views / materialized queries，让你可以轻松地在后台透明地进行这种缓存。那些物化表是由数据库更新的，所以程序代码不必担心它并且此外，根据查询优化器的复杂程度，可用于透明地优化查询。）
更新： 否/是投票问题有点不同，因为主要目的只是跟踪计数，不一定是整个信息（即谁投了赞成票）。因此，一个有效的实现可能是只跟踪是票和否票的累积数量。但是，您存储的信息越多（即谁投了赞成票，而不仅仅是多少），如果您选择这样做，您就可以用它做更多的事情（例如，在 Stackoverflow 中，我总是可以删除我的赞成票 - 如果您无法做到这一点你没有追踪谁投票）。在这种情况下，我再次建议不要尽早汇总，因为您会丢失某些信息。
【讨论】：
视情况而定。
如果您有很多用户，则计数可能会很长，并且会将大部分表/索引加载到内存中。
如果你做一个触发，那么你会在写作过程中失去一些时间，所以每个触发的后续动作都会慢一点。
两者之间的混合，异步提供一个关于关注者的统计表可能会给你最好的结果（写操作快，读操作极快）。
【讨论】：
或者，您可以使用两个数据容器：
【讨论】：