主页 / dba / 问题 / 279409
Accepted
Mikhail Aksenov
Asked: 2020-11-10 06:29:13 +0800 CST

在 SQL Server 上构建执行计划花费的时间太长

  • 772

我有一个 SQL Server 2014 实例 (12.0.2000.8) 和一个相当复杂的 SELECT 语句，大约有 20 个连接。此查询在 PostgreSQL、Oracle 和其他数据库上的相同数据集上运行良好，整个执行大约需要 1 分钟。

但在 SQL Server 上大约需要 40 分钟。我试图查看执行计划并开始等待……我试图通过从应用程序会话中执行查询来获取执行计划，但没有执行计划。

然后我得到了查询并在SQL Server Management Studio中询问“显示估计的执行计划”，我也开始等待。因此，看起来仅仅构建执行计划就需要花费太多时间。所有统计信息都使用“exec sp_updatestats”收集，我在 sys.stats 中检查了它——一切看起来都很好。所有指标都已到位。

我评论了所有加入并开始一一取消评论，并且

  SET STATISTICS TIME ON

表明每个未注释的连接都需要更长的时间来解析，例如 13 次连接的时间：

SQL Server parse and compile time:
   CPU time = 32250 ms, elapsed time = 32729 ms.

所以，这绝对是一个解析问题。

select count(*) from sys.index_columns
where object_id in (OBJECT_ID('tables_names'),...')

说有 128 列，当

select * from sys.indexes
where object_id in (OBJECT_ID('tables_names'),...')

返回具有 HEAP、CLUSTERED、NONCLUSTERED 索引的 43 行。

你能推荐看什么吗？为什么解析这么多？

更新：感谢“打破查询”和“使用 FORCE ORDER 提示”，但此 SQL 是由我们的应用程序生成的，因此使用应用程序逻辑可能需要付出很多努力，但在一般情况下他们应该是一个很好的解决方案。

第二次更新：应用 SP3 完成了整个工作 - 整个执行查询花费了不到一秒钟的时间。性能提高了两千倍:)

sql-server sql-server-2014

2 个回答

  1. Best Answer

    我有一个 SQL Server 2014 (12.0.2000.8)

    RTM 版本？我记得某些查询的编译持续时间（分钟）过长。该问题已在 RTM 后修复。我建议您将您的服务器打补丁到受支持的补丁级别 (SP3+)。

    • 13

  2. 我希望优化器花费大部分编译时间来考虑重新排序许多连接的不同方法。

    解决此问题的两个选项是：

    分解查询

    根据您的查询，一种可能有效的方法是将查询的关系部分与信息部分分开。这涉及将查询分成两部分，因此每个部分的连接更少（因此优化器挖掘的复杂性更低）。

    该方法本质上是采用过滤行或以其他方式提供查询逻辑的内容（在 where 子句、内部连接等中涉及的列）并仅运行该查询，将其插入到临时表中。

    然后在刚刚加入临时表的单独查询中添加其余的“信息”或显示相关内容。

    我第一次从 Erik Darling 那里听说过这个，这里有一个很好的例子：信息与关系

    请注意，这主要是为了避免广泛的结果和索引，但如果您能够完全消除第一个查询中的一些连接，它可能对编译有效。

    使用 FORCE ORDER 提示

    添加OPTION (FORCE ORDER)到查询的末尾应该会限制编译时间，尽管您可能必须尝试连接的书面顺序才能获得合理的执行计划（这可能会随着您的数据或模式的变化而随着时间而改变）。

    冒着成为 Erik Darling Data 粉丝的风险，这篇文章与您的情况相关，值得一读：长时间编译是否让您失望？

    那篇文章讨论了FORCE ORDER解决这个问题的方法（特别是使用计划指南，因为问题查询是由 EF 生成的，因此无法轻易在源中添加提示）。

    • 6

相关问题