在我们的应用程序中，我们有以下数据处理层：
如果从 SSMS 执行，一个存储过程将在 40 秒内运行，如果手动调用 SSIS 包，则大约在同一时间运行。
但是，如果 SSIS 包由 .NET 应用程序调用，则查询需要超过 14 小时才能运行，并且所有处理器都排平。
查看执行计划，似乎如果从 SSMS 运行该过程或手动触发 SSIS 包然后调用该过程，SQL Server 将使用基于当前统计数据的合理计划。
但是，如果从 .NET 应用程序调用 SSIS 包，则 SQL Server 会创建一个新计划，使用完全错误的统计信息。以下事情没有区别：
我们通过在查询中使用 MAXDOP 提示来伪造分辨率，但我的问题是：
当通过我描述的方法使用相同的参数和相同的数据调用时，基于完全不正确的统计信息，什么会使 SQL Server 产生完全不同的计划？
看起来你在你的独白中主要回答了你的其他问题，这些things that made a difference是在受到参数嗅探影响后强制重新编译的标准列表。
要回答您的最后一个问题，标记为my question is this：
当通过我描述的方法使用相同的参数和相同的数据调用时，基于完全不正确的统计信息，什么会使 SQL Server 产生完全不同的计划？
答案是计划缓存非常特定于对呈现查询的会话有效的SET 设置。不同的 SET 设置可能需要非常不同的计划，例如设置SET ANSI_NULLS。很可能，您从 SSMS 的连接与您的 .Net 应用程序具有不同的设置。这可以通过使用 SQL Server Profiler 跟踪Existing Connections和来轻松验证Login Audits，其中显示了SET设置。
结果是看似相同的查询将产生一个，Cache Miss并且必须创建一个新的查询，这在某种程度上基于为该查询实例提供给 SQL Server 的参数。