2

我们有表格Site并且Content在我们的数据库中。

每个站点由不同的客户运营，每个站点都有自己的内容。

在网站的前端，我们提供了一个搜索框，它在内容表上使用全文/自由文本搜索来返回结果，但每个网站只能从其自身返回结果，而不是从数据库中的其他网站返回结果。

SQL Server 查询优化器在这里表现不佳。如果它针对内容很少的站点优化查询，那么对于内容很多导致超时的站点，查询的执行会非常糟糕。

我们知道我们可以添加OPTION(RECOMPILE)到查询的末尾来解决这个问题，但我的问题是......

为每个站点创建一个缓存表，以便可以定期缓存每个站点的内容并让搜索存储过程查找缓存表而不是使用参数会更好吗？

仅在添加/更改内容时才会更新/刷新缓存。

我的想法是，这将......

a) 减少被搜索表的大小，只包含正确站点的记录

b) 允许全文搜索为每个站点生成更准确的内容索引

c) 允许查询优化器独立缓存每个站点的优化查询

它是否正确？我这样做对吗？

4

2 回答 2

2

您是否尝试过“选项（优化未知）”？无论预期有多少行，这将为您的所有输入生成一个通用执行计划。对于较小的站点，它将比以前花费更多，但对于较大的站点应该没问题，对于较小的站点仍然可以接受。这是一篇详细介绍内部工作原理的博客文章：http ://www.benjaminnevarez.com/2010/06/how-optimize-for-unknown-works/ 。

于 2012-05-23T21:10:06.260 回答
1

你在问正确的问题。这是一个权衡。您必须决定哪个对您的情况更好/或更差。

您会经常添加网站吗？您预计每个站点总共有多少行？一般来说，SQL Server 2008 全文搜索最多可以处理 10 的数百万行。如果您期望更多，我会将站点拆分为单独的表。

请记住，即使您拆分为多个表，由于从给定搜索词返回的数量或单词，您的查询计划仍然可能有很大差异。您可能仍需要考虑使用 OPTION(RECOMPILE)。

以下是每条路线的一些优点：

单表

  • 无需更改架构即可添加其他站点。
  • 更容易管理。
  • 无需担心单独的存储过程或动态 SQL 来处理多个表。

多个表

  • 较小的表和索引（不需要 SiteId）。
  • 由于目录更小，全文性能更好。
  • 可能更好地分离数据。
于 2012-05-24T21:35:54.760 回答