问题标签 [sql-execution-plan]

我正在尝试调试一个相当复杂的存储过程，它连接了许多表（10-11）。我看到对于树的一部分，估计的行数与实际的行数有很大的不同——在最坏的情况下，SQL 服务器估计将返回 1 行，而实际上返回了 55,000 行！

我试图弄清楚为什么会这样 - 我的所有统计数据都是最新的，并且我已经在几个表上使用 FULLSCAN 更新了统计数据。我没有使用任何用户定义的函数或表变量。据我所见，SQL Server 应该能够准确估计将要返回多少行，但它会继续选择一个计划来执行数万次 RDI 查找（当它预计只执行 1或 2）。

我可以做些什么来尝试理解为什么估计的行数会减少这么多？

更新：所以查看计划，我发现了一个特别可疑的节点 - 它使用以下 predecate 对表进行表扫描：

此谓词返回整个表（630 行 - 表扫描本身不是性能不佳的根源）但是 SQL 服务器的估计行数仅为 37。然后 SQL 服务器继续在 RDI 上执行几个嵌套循环查找、索引扫描和索引查找。这会是我严重误判的根源吗？如何让它估计更合理的行数？

我有一个存储过程，它根据DATEADD函数的结果进行过滤 - 我的理解是，这类似于使用用户定义的函数，因为 SQL 服务器无法根据该函数的输出存储统计信息，因此难以评估执行计划。

查询看起来有点像这样：

（所以它不可能预先计算的结果DATEADD）

我看到的是一个可怕的执行计划，我认为这是由于 SQL 服务器错误地估计从树的一部分返回的行数为 1，而实际上它约为 65,000。然而，当数据库中存在不同（不一定更少）数据时，我已经看到相同的存储过程在很短的时间内执行。

我的问题是——在这种情况下，查询优化器如何估计函数的结果？

更新：仅供参考，我更感兴趣的是了解为什么有时我会得到一个好的执行计划，而为什么其他时间我没有 - 我已经很清楚我将如何解决这个问题在长期。

我正在尝试在 SQL Server 2005 中执行以下过程。我能够在我的开发服务器中执行它，当我尝试在 Live Server 中使用它时，我收到错误“内部查询处理器错误：查询处理器无法生成查询计划。有关详细信息，请联系客户支持服务”。我使用相同的数据库和相同的格式。当我们在网上搜索时，它显示了一些要在 sql server 2005 中使用的修复程序以避免此错误，但我的 DBA 已确认所有补丁程序都已在我们的服务器中更新。谁能给我一些线索。

询问：

如何使用查询分析器比较表上索引的性能？

我想通过 Estimated Execution Plan 运行相同的查询两次，一次使用索引，一次不使用，并对生成的表扫描/索引扫描进行很好的比较。

我尝试过创建索引...、选择...、删除索引...、选择。我希望第一个查询使用索引，第二个查询没有索引，但是两个执行计划都将使用索引。

有没有人有一个查询来搜索 SQL2005/2008 的计划缓存，以识别在其执行计划中具有表/索引扫描的查询或存储过程？

sql server 是否缓存函数的执行计划？

问题一：

当我们执行查询时，每次执行查询时，执行计划都会改变吗？

如果是，有任何性能影响吗？

如果不是，那么如果我们更改表中的某些内容，即添加索引，数据库如何知道可以使用某些内容来更改执行计划以加快执行速度？

问题2：

但是执行连接查询时的一般执行顺序是什么，特别是如果有很多连接（外部，内部，自然，如果有很多外部）。

我正在寻找一个应用程序来显示 linq 表达式会做什么，特别是关于在查询中对同一列表进行多次访问的使用。

更好的是，该工具会判断 linq 查询是否良好。

我有一张桌子，我们就叫它吧History。主键（又名聚集索引）称为HIST_ID. 该表在开发数据库中有大约 2300 行。现在考虑以下两个查询：

查询一：

查询 2：

唯一的区别是or @x is null最后。但是，第一个查询执行索引查找，第二个查询执行索引扫描。是什么赋予了？

先发制人的答复 - 不，选项（重新编译）没有帮助。

补充：我想要一些有说服力的事实，而不是猜测。我自己可以猜出十几个可能的原因。但这里真正的问题是什么？

当从参数化查询更改为非参数化查询时，我无法理解 SQL Server 中我的语句的估计查询计划的行为。

我有以下查询：

此查询由 Linq2SQL 表达式生成并从 LINQPad 中提取。这会产生一个很好的查询计划（据我所知）并在大约 10 秒内在数据库上执行。但是，如果我用精确值替换参数的两种用途，即用 '= '1fc66e37-6eaf-4032-b374-e7b60fbd25ea' ' 替换两个 '= @p0' 部分，我会得到一个不同的估计查询计划和查询现在运行时间更长（超过 60 秒，还没有看透）。

为什么执行看似无辜的替换会产生效率低得多的查询计划和执行？我已经使用“DBCC FreeProcCache”清除了过程缓存，以确保我没有缓存错误的计划，但行为仍然存在。

我真正的问题是我可以忍受 10 秒的执行时间（至少在很长一段时间内），但我不能忍受 60 多秒的执行时间。我的查询将（如上所述）由 Linq2SQL 生成，因此它在数据库上执行为

这会产生同样糟糕的执行时间（我认为这很奇怪，因为这似乎是在使用参数化查询。

我不是在寻找关于创建哪些索引等的建议，我只是想了解为什么查询计划和执行在三个看似相似的查询上如此不同。

编辑：我已经上传了非参数化和参数化查询的执行计划，以及带有不同 GUID的参数化查询的执行计划（如Heinz建议的） here

希望它可以帮助你帮助我:)