【问题标题】:Complexity Difference Between Where Clause Inside Query and Where Clause Inside Conditional Split In SSIS查询内部的 Where 子句与 SSIS 中条件拆分中的 Where 子句之间的复杂性差异
【发布时间】:2011-09-27 14:12:21
【问题描述】:

我一直在想,这两种情况在复杂度上有什么区别:

案例 1:一个 OLE DB 源查询,写法如下:

 select *
 from A
 where A.value > 1

案例 2:OLE DB Source 查询,where 子句放在 Conditional Split 中

 select * from A

在 OLE DB 源查询之后带有条件拆分,包含:值 > 1。

性能方面,有什么不同吗?对于更复杂的查询,它是否也有任何重大影响?

【问题讨论】:

    标签: sql sql-server ssis


    【解决方案1】:

    是的,存在性能差异。

    案例 2 将返回表 A 中的所有数据记录,并将它们存储在 SSIS 内存缓冲区中,然后再将它们传递给条件拆分组件进行过滤。

    案例 1 立即将较小的数据集返回到 SSIS 内存缓冲区。

    如需进一步阅读,请查看:

    【讨论】:

    • +1 总是让 sql 语句消除不必要的行。很少有数据流任务在消除行、删除重复项或对数据排序等方面优于数据库引擎的情况。
    【解决方案2】:

    SSIS 的主要目的是从异构源(例如文本文件、Excel 电子表格等)导入/导出。您可以在将数据加载到服务器之前进行某种验证,并且可以在某处记录“错误”记录。 但是,如果您打算仅将 SSIS 与 SQL 查询一起使用,并且在文本文件中没有任何验证或错误日志记录,您应该寻找另一种解决方案(链接服务器、OPENROWSET 等等)。

    但如果你还在看 SSIS,你应该在 SQL 查询或数据源中包含所有可能的逻辑。

    有一篇关于如何使用 SSIS 准备快速提取的文章:http://www.sqllion.com/2009/04/faster-extraction-loading-by-ssis/

    Try to avoid type casting or manipulating data types inside the SSIS package as it is an additional overhead for SSIS. Do it prior to the package or do typecasting in the source query of OLE DB Source component.
    

    【讨论】:

      猜你喜欢
      • 2014-10-18
      • 2020-05-31
      • 1970-01-01
      • 1970-01-01
      • 2019-01-29
      • 2018-07-08
      • 1970-01-01
      • 2012-06-06
      • 1970-01-01
      相关资源
      最近更新 更多