我们的数据库中有表Site和Content。
每个网站都由不同的客户运营，每个网站都有自己的内容。
在网站的前端，我们提供了一个搜索框，该搜索框使用内容表上的全文/自由文本搜索来返回结果，但每个网站只能返回其自身的结果，而不能返回数据库中的其他网站。
SQL Server查询优化器在此处表现不佳。如果它优化了内容很少的网站的查询，则查询会对包含大量内容导致超时的网站执行可怕的操作。
我们知道我们可以在查询末尾添加OPTION(RECOMPILE)来解决此问题，但我的问题是这个......
为每个站点创建一个缓存表是否更好，以便可以定期缓存每个站点的内容，并让搜索存储过程使用参数查找缓存表？
只有在添加/更改内容时，才会更新/刷新缓存。
我的想法是，这会.......
a）减少要搜索的表的大小，使其仅包含正确站点的记录
b）允许FullText搜索为每个站点生成更准确的内容索引
c）允许查询优化器独立缓存每个站点的优化查询
这是对的吗？我是这样做的吗？
答案 0 :(得分：2)
您是否尝试过“选项（针对未知进行优化）”？这将为您的所有输入生成一个通用执行计划，而不管预期的行数。对于较小的站点，它将比以前花费更多，但对于较大的站点应该是好的，并且对于较小的站点仍然可以接受。这是一篇博文，详细介绍了内部工作原理：http://www.benjaminnevarez.com/2010/06/how-optimize-for-unknown-works/。
答案 1 :(得分：1)
你在问正确的问题。这是一种权衡。您必须根据自己的情况决定哪个更好/更差。
您会经常添加网站吗？您期望总计和每个站点有多少行？通常，SQL Server 2008全文搜索最多可以完成数百万行的操作。如果您期望更多，我会将网站拆分出来。
请注意，即使您拆分为多个表，由于从给定搜索字词返回的数字或单词，您的查询计划仍可能会有很大差异。您可能仍想考虑使用OPTION（RECOMPILE）。
以下是每条路线的一些优点：
单人表
多个表格