【问题标题】:Option Recompile makes query fast - good or bad?选项重新编译使查询快速 - 好还是坏?
【发布时间】:2011-05-15 14:06:12
【问题描述】:

我有两个 SQL 查询,每个查询大约有 2-3 个 INNER JOINS。我需要在它们之间做一个 INTERSECT。

问题是个别查询工作速度很快,但相交后总共需要大约 4 秒。

现在,如果我在整个查询的末尾添加一个 OPTION (RECOMPILE),则查询再次运行良好,几乎立即返回!

我知道选项 recopile 会强制重新构建执行计划,所以我现在很困惑,如果我之前的查询需要 4 秒更好,或者现在重新编译的查询更好,但需要 0 秒更好。

【问题讨论】:

    标签: sql sql-server optimization


    【解决方案1】:

    除了回答你提出的问题,你应该这样做:

    更新您的统计数据:

    EXEC sp_updatestats
    

    如果这不起作用,请重建索引。

    如果这不起作用,请查看OPTIMIZE FOR

    【讨论】:

    • 是否定期执行?如果没有,我不知道如何管理数据库中的索引......关于如何避免需要定期执行此命令的任何想法?或者,如果这是不可能的,您是否是定期执行此操作的最佳方式,我的意思是无需应用程序执行此操作?
    • 我建议你单独问一个问题。
    【解决方案2】:

    指定了 WITH RECOMPILE SQL Server 不缓存此存储过程的计划, 存储过程每次执行都会重新编译。

    每当第一次在 SQL Server 中运行存储过程时,都会对其进行优化,并编译查询计划并将其缓存在 SQL Server 的内存中。缓存后每次运行相同的存储过程时,都会使用相同的查询计划,从而无需在每次运行时对相同的存储过程进行优化和编译。因此,如果您需要每天运行 1000 次相同的存储过程,可以节省大量时间和硬件资源,而 SQL Server 也不必那么辛苦。

    您不应使用此选项,因为使用此选项会失去使用存储过程替换 SQL 查询所获得的大部分优势。

    【讨论】:

    • 但是对于 OP,避免这个选项意味着 SQL Server 每次执行查询时花费的时间要长 100-200 倍,并且可能会浪费大量的 CPU 和磁盘吞吐量,因为它总是使用错误的查询计划.除非有办法弄清楚如何让 SQL Server 缓存一个好的计划,否则OPTION (RECOMPILE) 会好得多,因为与坏计划的执行时间相比,计划生成/优化时间是微观的……
    猜你喜欢
    • 2016-10-19
    • 2014-11-16
    • 1970-01-01
    • 2015-07-19
    • 2014-01-18
    • 1970-01-01
    • 2019-02-25
    • 2018-07-04
    • 1970-01-01
    相关资源
    最近更新 更多