每当我在管理工作室中创建即席查询时，连续运行的查询没有任何更改都不显示任何解析/编译时间，因为看起来algebrizer已经为查询分配了一个哈希，它只是重用了该计划。对于一批查询，这甚至是正确的。但是，一旦我引入临时表的创建，它似乎永远不会缓存计划，因为我总是看到解析和编译时间几乎是执行时间的75％
另一方面，当我从Java应用程序运行相同的查询（创建临时表，使用它并删除它）时，我没有看到同样的症状。似乎每次对查询的连续调用都很快，从不会被解析/编译时间所困扰。不同之处在于查询已参数化并通过sp_executeSQL运行。
这使得在SSMS中调试查询变得困难，因为我无法使时间与应用程序保持一致。我是否需要实际接受我的即席查询并通过SSMS中的sp_executeSQL运行它以避免这种情况？
编辑：是的，通过sp_executeSQL运行它确实避免了解析时间。
答案 0 :(得分：1)
好吧，the doc for sp_executeSQL says：
可以使用sp_executesql代替存储过程来执行 当参数值发生变化时，Transact-SQL语句多次出现 声明是唯一的变化。因为Transact-SQL 语句本身保持不变，只有参数值 更改后，SQL Server查询优化器很可能会重用 它为第一次执行生成的执行计划。
您所看到的行为似乎就是这样。所以，是的，为了匹配应用程序的性能足迹，您可能需要使用sp_executesql。
你可以做一些事情，比如使用计划提示或forcing query plans，但这看起来既丑陋又有风险。