针对Web使用优化数据库（阅读比写作多）

Question

我正在尝试布置表格，以便在面向公众的新网站中使用。看看有多少阅读而不是写数据（猜测＆gt; 85％读数）我想优化数据库以供阅读。

每当我们列出成员时，我们都计划显示有关成员的摘要信息。类似于stackoverflow使用的信誉点和徽章的东西。我不想在每次进行搜索时都使用子查询来查找信息，而是希望在成员表中有一个“计算”字段。

每当启动会影响此字段的操作时，假设该成员获得更多分数，我们只需通过运行查询来计算新值来更新此字段。

显然，需要更新此字段，但即使字段不同步，我们也可以重新运行查询以更新此字段。

我的问题：这是优化数据库的合适方法吗？或者子查询是否足够快，性能不会受到影响。

Answer 1

分为两部分：

1. 缓存
2. Tuned Query
   1. 索引视图（AKA物化视图）
   2. 调整表

最佳解决方案需要尽可能少地查询数据库，这需要缓存。但是你仍然需要一个查询来填充缓存，并且缓存需要在过时时刷新...

Indexed views是下一个考虑因素。因为它们是索引的，所以查询比普通视图（相当于子查询）更快。非聚簇索引也可以应用于索引视图。问题是索引视图（一般的物化视图）非常受限于它们支持的内容 - 它们不能具有非确定性函数（IE：GETDATE（）），极其有限的聚合支持等。

如果索引视图无法处理您需要的内容，则会转储数据的表格。通过SQL Server作业刷新是下一个选择。与索引视图一样，将应用索引以更快地获取数据。但是数据更改意味着清理索引以确保查询尽可能地运行，并且此维护可能需要一些时间。

Answer 2

最便宜的数据库查询是您根本不必对数据库运行的查询。

在您描述的场景中，使用高性能缓存技术（例如：memcached）将查询结果存储在应用程序中可能比尝试欺骗数据库以实现高度可伸缩性要好得多。

Answer 3

  

程序优化的第一条规则：不要这样做   程序优化的第二条规则（仅限专家！）：不要这样做。

     迈克尔·杰克逊

如果您只是设计表格，我会说，优化绝对是不成熟的。 您可能希望在几天后重新设计数据库，您可能会发现事情工作得很快而没有任何聪明的黑客，您可能会发现它们工作缓慢，但方式与您预期的不同。如果你现在开始优化，在任何一种情况下都会浪费你的时间。

您描述的方法通常很好;您可以获得一些预先计算的值，使用触发器/ SP保持数据一致性，或运行作业以不时更新这些值。

Answer 4

所有数据库都超过85％只读！通常高九十年代。

在需要时调整它，而不是之前调整它。