我有一个查询，它从多个视图中进行选择并且 I/O 相当繁重。如果我使用 Management Studio 执行此查询，它会在 16 个 CPU 中的大部分使用并行性并在 10 秒内完成。但是，当从 SpotFire（Tibco 的产品）执行它时，它仅使用 1 个 CPU，并且可能需要数小时才能完成。
如果我使用查询提示OPTION (MAXDOP 1) ，我可以在 Management Studio 中重现该问题。
我当时认为这可能是 SpotFire 问题，但它使用 Microsoft JDBC 驱动程序进行连接，我看不到有关并行性的连接属性。我已经使用 Profiler 确认来自 SpotFire 和来自 Management Studio 的查询看起来完全一样。这。相同的。唯一的区别似乎是并行执行。
谁能提供有关为什么会发生这种情况的见解？
！解决了！[有点儿]
我重新运行 SQL Profiler 跟踪，发现查询确实相同，但执行方式不同。
来自 SpotFire：
declare @p1 int
set @p1=0
declare @p2 int
set @p2=0
declare @p7 int
set @p7=0
exec sp_cursorprepexec @p1 output,@p2 output,NULL,N'SELECT a, b, c , d FROM MyView',16,8193,@p7 输出
选择 @p1, @p2, @p7
从 Management Studio：
从 MyView 中选择 a、b、c、d
然后，我向 SQL Profiler 添加了两个新事件并重新运行查询：
- 性能/并行度
- 性能/全部显示计划
这表明来自 SpotFire 的查询使用的是 DOP 0 (BinaryData = 0x00000000)，来自 Management Studio 的查询使用的是 DOP 12 (BinaryData = 0x1200000)。接下来，SHOWPLAN 向我展示了 SpotFire 查询在将数据返回给客户端之前将视图中的结果插入到临时表中。
那么它为什么要这样做呢？可能是因为sp_cursorprepexec语句。但为什么这会导致 DOP 降至 0？我不知道。
我认为“解决方案”将与 SpotFire 一起使用并可能调整 JDBC 连接字符串。
有两种标准方法可以影响这一点
SQL Server 2008 资源调控器和一些跟踪标志会影响它。我怀疑 Tibco 正在使用资源调控器，因此它可能是一个跟踪标志。
我见过的另一种选择是 SET IMPLICIT TRANSACTIONS ON。
如果没有跟踪标志，没有隐式事务，也没有 MAXDOP 提示，那么查询就不一样了。
编辑，问题更新后
您应该能够更改一些准备和/或光标设置。示例： http: //www.streamreader.org/serverfault/questions/177391/impact-on-sql-2000-performance-of-jdbc-selectmethodcursor
您可以尝试为指定 maxdop 提示的查询创建计划指南；链接的文章显示了当您无法控制正在执行的查询时它的用途，以及控制 sp_cursorprepexec 查询的示例。