Mik*_*nov 9 sql-server optimization execution-plan sql-server-2014
我有一个 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 完成了整个事情 - 整个执行查询不到一秒钟。性能提高了两千倍:)
Dan*_*man 13
我有一个 SQL Server 2014 (12.0.2000.8)
RTM版？我记得某些查询遇到过长的编译持续时间（分钟）。该问题已在 RTM 后修复。我建议您将服务器修补到受支持的补丁级别 (SP3+)。
我希望大部分编译时间都花在优化器考虑重新排序许多连接的不同方法上。
解决此问题的两个选项是：
根据您的查询，一种可能有效的方法是将查询的关系部分与信息部分分开。这涉及将查询分解为两部分，因此每个部分的连接较少（因此优化器挖掘的复杂性较低）。
该方法本质上是采用过滤行或以其他方式提供查询逻辑的内容（涉及 where 子句、内部联接等的列）并仅运行该查询，将其插入到临时表中。
然后在一个单独的查询中添加其余的“信息”或显示相关的东西，这个查询只是连接到临时表。
我第一次从 Erik Darling 那里听说过这个，这里有一个很好的例子：Informational vs. Relational
请注意，这主要是为了避免使用广泛的结果和索引，但如果您能够完全消除第一个查询中的某些连接，则它可以有效地进行编译。
添加OPTION (FORCE ORDER)到查询的末尾应该会限制编译时间，尽管您可能必须对连接的写入顺序进行试验以获得合理的执行计划（这可能会随着数据或架构的变化而随着时间的推移而变化）。
冒着被认为是 Erik Darling Data 粉丝男孩的风险，这篇文章与您的情况相关，值得一读：编译时间长是否会让您失望？
那篇文章讨论了FORCE ORDER解决这个问题的方法（特别是使用计划指南，因为问题查询是由 EF 生成的，因此无法轻松地在源中添加提示）。