【问题标题】:Stored Procedure Execution Plan - Data Manipulation存储过程执行计划——数据操作
【发布时间】:2010-10-05 20:40:47
【问题描述】:

我有一个处理大量数据的存储过程(在这个例子中大约有 5m 行)。性能差异很大。我在短短 15 分钟内运行了该过程,并且看到它运行了长达 4 小时。

为了维护,为了验证逻辑和处理是否正确,我们将 SP 分成几个部分:

  1. TRUNCATE 并填充一个工作表(索引),我们稍后可以使用自动化测试工具进行验证。

  2. 将几个表(包括其中一些工作表)连接在一起,以生成另一个工作表

重复 1 和/或 2 直到产生最终输出。

我担心这是一个单一的 SP,因此在第一次运行时会得到一个执行计划(甚至是 WITH RECOMPILE)。但那时,工作表(Work 模式中的永久表)是空的。

我担心无论索引方案如何,执行计划都会很差。

我正在考虑拆分 SP 并从其中调用单独的 SP,以便在构建工作表中的数据后,它们可以利用重新评估的执行计划。我还看到了使用 EXEC 运行动态 SQL 的参考,这显然也可能得到 RECOMPILE

我仍在尝试获得SHOWPLAN 权限,所以我很盲目。

【问题讨论】:

  • 5m 行并不大。 Crikey,在 DB2/z 中,我们有比这更大的配置表 :-)
  • 5m 刚好够大,执行计划似乎开始变得很重要。我们有一些每日提要超过 2500 万行。

标签: sql sql-server stored-procedures sql-execution-plan


【解决方案1】:

在某些情况下,我看到执行时间/查询计划的这种多样性程度归结为统计数据。我建议在运行进程之前针对您正在使用的表运行一些更新统计信息的测试。这将强制通过 SQL 重新评估执行计划,并且我怀疑会为您提供更一致的结果。此外,您可能会很好地查看执行时间的差异是否与您的 dbas 重新索引作业相关。也许您还可以在每次运行之前收集一些索引运行状况统计信息。

如果不是,正如其他回答者所建议的那样,您更有可能遇到锁定和/或争用问题。

祝你好运。

【讨论】:

    【解决方案2】:

    这是某种输入或输出,还是您正在创建报告?如果是提要,我建议您更改流程以使用 SSIS,它应该能够非常快速地移动 500 万条记录。

    【讨论】:

    • 这是一个后端业务流程,但是是的,我一直在推动一些工作(适当的)在 ETL 中执行,但无济于事。
    【解决方案3】:

    您是否能够确定是否存在任何锁定问题?您是否在足够小的事务中运行 SP?

    将其分解为子程序应该没有任何好处。

    在没有基本优化资源的情况下工作时,应该有人关心您的工作效率。这表明可能还有其他可能的看不见的问题。

    【讨论】:

    • 他们告诉我我可能会在下周之后获得 SHOWPLAN ;-)
    【解决方案4】:

    您是对的,在您从整个流程的多次执行中获得“实际”执行计划之前,您很难清楚地了解幕后发生的事情。

    也许需要考虑一点。您的工作表是物理的临时表吗?如果它们是物理的,您将通过将新数据插入没有索引(即堆)的新表中来获得性能提升,然后您可以在插入所有数据后在其上构建索引。

    另外,您的流程的目的是什么。听起来您正在移动相当多的数据,在这种情况下,您可能希望考虑使用分区。您可以相对轻松地在主表中输入和输出数据。

    希望我所详述的内容很清楚,但请随时提出更多问题。

    干杯,约翰

    【讨论】:

      【解决方案5】:

      您确定您看到的可变性是由“糟糕的”执行计划引起的吗?这可能是一个原因,但也可能有许多其他原因:

      • 数据库机器上的“其他”负载
      • 使用不同的数据时,可能存在“简单”和“困难”数据
      • 必须分配更多内存/文件存储的问题
      • ...

      您是否尝试过多次使用相同的数据运行 SP?

      另外,为了找出导致运行时/可变性的原因,我会尝试进行一些详细的测量,以将问题归结为代码的特定部分。 (最简单的方法是在 sp 的各个点插入一些日志调用)。然后尝试解释为什么该部分很慢(除了“5M 行 ;-))并想办法让它更快。

      目前,我认为在走“拆分 sp”路线之前有几个问题需要回答。

      【讨论】:

      • 昨晚跑了 11 个小时才被我杀死。
      • 这听起来像您编写 SP 的方式,您可以随时重新启动它而不会太麻烦。因此,与其做“整个事情”,不如做第一步(并注释掉其余部分),看看这需要多长时间,然后是第一步和第二步,依此类推。这样你应该能够找到慢的部分。
      【解决方案6】:

      在下面的链接中获取“剖析执行计划”的免费副本,也许您可​​以从中获得一两个提示,让您了解您的 SP 背后的真实情况。

      http://dbalink.wordpress.com/2008/08/08/dissecting-sql-server-execution-plans-free-ebook/

      【讨论】:

        【解决方案7】:

        我能想到的唯一一件事是,当没有数据时执行计划会出错,因为使用表扫描而不是索引是错误的,因为当整个表都可以放入内存时,表扫描速度非常快。由于创建执行计划时没有数据,您是否实际观察到或确定正在发生其他负面影响?

        您可以在查询中force usage of indexes...

        在我看来,你可能走错了路。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2020-10-16
          • 2018-10-20
          • 1970-01-01
          • 2015-09-01
          • 2010-10-22
          • 1970-01-01
          相关资源
          最近更新 更多