Question

我正在直接运行查询，它本质上是微不足道的：

SELECT * FROM [dbo].[vwUnloadedJobDetailsWithData] WHERE JobId = 36963

当我从Management studio运行此查询时，查询甚至不需要一秒钟。当我从表适配器中运行它时超时。我已多次修复此问题，但解决方案很荒谬。如果我从我的xsd文件中删除表适配器并重新创建它，查询时间与管理工作室的查询时间相匹配大约两天，但我必须重新部署哪个是asinine。

任何可能导致这种情况的见解都将非常感激。我已经看到了另一个关于此的问题，但在查询之前涉及set arithabort的解决方案对我没有影响。

编辑：有人要求我显示调用查询的代码。现在，当我进入我的xsd文件并且只是预览数据时会发生这种情况，但为了清楚起见，这里是：

using (TEAMSConnection connection = new TEAMSConnection())
{  
    connection.OpenConnection();

    _JobDetailsDAO jobDetailDao= new _JobDetailsDAO(connection);
    return jobDetailDao.GetUnloadedJobDetailsByJobId(jobId);

}

在处理连接时，数据库连接已关闭。使用这行代码：

if (_DBConnection != null && _DBConnection.State == ConnectionState.Open)
    _DBConnection.Close();

Edit2：我运行了一个跟踪，这里是正在设置的设置选项

设置quoted_identifier 设置arithabort 设置numeric_roundabort关闭设置ansi_warnings 设置ansi_padding 设置ansi_nulls 设置concat_null_yields_null 设置cursor_close_on_commit off 设置implicit_transactions关闭设置语言us_english 设置dateformat mdy 设置datefirst 7 set transaction isolation level read committed

我把它添加到我在管理工作室中生成的查询中，它仍然在不到一秒的时间内运行。我甚至完全按照跟踪复制了查询。

exec sp_executesql N'SELECT * FROM [dbo].[vwUnloadedJobDetailsWithData] WHERE JobID = @JobId',N'@JobId int',@JobId=36963

它仍然不到一秒的回归时间。我很困惑。

谢谢，约什

Answer 1

最可能发生这种情况的原因是ssms和ado.net之间SET选项的差异。这种差异导致（重新）建立可能不是最佳的执行计划。

Answer 2

好吧，我找不到任何可以继续允许我使用数据集的解决方案，所以我直接在代码中使用SqlDataAdapter而不是使用自动生成的TableAdapter。

根据跟踪它执行完全相同的查询，但到目前为止它的工作原理。它可能不会在两天内，但现在它似乎有效。

Answer 3

只是想大声思考：也许有另一个进程/人造成的锁？有没有人同时更新同一行？是否有人从Management studio或具有Open Table功能的查询分析器打开表并使用过滤器？尝试使用sp_who2

查找锁

Answer 4

一些想法：

我称之为存储过程的参数嗅探。尝试OPTION (RECOMPILE)提示，因此您发送的SQL如下所示：

exec sp_executesql
    N'SELECT *
         FROM [dbo].[vwUnloadedJobDetailsWithData]
         WHERE JobID = @JobId
         OPTION (RECOMPILE)',
    N'@JobId int',
    @JobId=36963

说明：生成并缓存查询计划时，它可能是一个糟糕的非典型值。说JobID通常是非常有选择性的，但对于那个执行它不是。当您运行查询时，下一个计划的缓存计划对于下一个选择性JobId是错误的。计划将因各种原因重新编译，但重新编译的价值很重要。

否则，Jobid的确切数据类型是什么？如果它是smallint，则该列将在参数化查询中转换为int。当使用常量时，它将是smallint。确保正确定义了类型：这在SQL代码中很重要。

查询立即运行时，数据集超时

4 个答案: