Sql server 何时使用“针对未知对象优化”的经验

我已经阅读了SQLServer2008“优化未知”查询计划选项背后的理论和观点。我很了解它的功能

我做了一些有限的实验，发现使用热缓存时，只有在>100k行上才有好处。然而，这是在一个简单的表和查询上进行的，没有连接、过滤等。在一个冷缓存上，图片无疑会更加有利于它

我目前没有一个生产系统来测试前/后。因此，我很好奇，在测试之前/之后是否有人做过测试，并在何时使用此选项和何时不使用此选项方面有任何有用的发现

更新：

我创建了一个包含3个col的表，UID上有一个PK，Col2（int）上有一个索引。所有处理都是针对Col2的。所示为行数和时间（DATEDIFF*1000000）：

---

当您的数据倾斜到一个参数值生成的计划完全不适合该参数的另一个潜在值时，您可以使用它。i、 e.解决参数嗅探问题

---

你问题的其余部分似乎与提示或可回答IMO的目的无关。

我可以说，由“@UID=1”制定的计划将导致索引扫描，而不是搜索，这对“@UID=100000”总是有害的。MSDN的博客对任何最佳实践都非常模糊，只给出了您在这里所说的内容。问题的其余部分强调了一种加剧局势的情况，因此，在我看来，这是非常相关的，因为它是完全无法回答的。如果没有执行计划的上下文，行数本身就没有任何意义。我理解这一点。我所要求的只是一些案例研究。这很像“超线程是否会伤害或帮助SQL Server”问题。没有“是/否”的答案。找到任何类型答案的唯一方法是研究一些案例研究并推断模式。这是针对这个场景进行的，并得出了一个结论。它也可以满足我的要求。@IanC-我个人只在确定了一个特定的参数嗅探问题之后才使用过它。我假设在我不使用它的情况下，我隐式地假设任何参数值都会这样做

optimizeforunknown

也不会有任何伤害。@Martin我也在做同样的假设。了解排序扫描和搜索的查询计划之间的区别让我感到紧张。然而，我发现，对于我给出的测试用例来说，在错误的地方使用此提示的速度几乎慢了3倍（请参见编辑）。所以“只用它”似乎不是个好主意。

Type        1,000   5,000   20,000  100,000
Normal      0.3086  6.327   26.427  144.83, 141.126
Recompile           117.59  584.837 
For Unknown 0.8101  6.52    26.89   143.788, 143.248