SQL参数嗅探是否可能重新编译对局部变量没有帮助

Question

我正在使用private void button_Click(object sender, EventArgs e) { Button btn = sender as Button; Clipboard.SetData("Bitmap", btn.BackgroundImage); richTextBox1.Paste(); } 通过一些参数传递复杂的选择。以这种方式执行它比通过将其从存储过程中取出并声明变量要慢得多。

我已经看到很多关于SQL参数嗅探的问题，我的场景听起来可能就是这种情况。但是，即使在调用sp_executesql或修改外部Select DBCC FREEPROCCACHE之后，与在存储过程外部编写相同查询相比，它仍然使用不同且无效的执行计划。

但是仍然使用存储过程但是将参数的副本设置为局部变量将使用有效的执行计划。

此方案是否排除SQL参数嗅探的原因？因为我重新编译查询肯定没有它使用的预先存在的执行计划。如果是这样，可能出现这种行为的其他原因？

只是为了让您了解sql查询，您可以在下面看到它（通过Entity框架生成的Messy）。这是快速查询，但是当放入Option (Recompile) proc并且变量被取出并放入参数时，它会生成低效的执行计划

sp_executesql

Answer 1

我认为你的问题是设计而不是数据，多个子查询更昂贵，特别是使用OR运算符

我宁愿使用多个表变量并留下外连接

Answer 2

再次遇到同一问题，并希望发布对我有用的答案。

我在与查询相关的各种表上运行了UPDATE STATISTICS [TableName] WITH FULLSCAN，此后它的工作速度与使用局部变量的速度一样。

值得注意的是，如果没有WITH FULLSCAN，它仍然很慢。另外，在更新统计信息之后，第一次运行的速度很快，然后下一次运行的速度又变慢了，所以我不得不不断更新统计信息才能使其快速运行，然后我尝试更新统计信息，运行查询（快速运行），然后呼叫DBCC FREEPROCCACHE，这似乎可以解决问题，因此每次我运行它都很快

我想这是问题所在，而不是参数嗅探。