SqlCommand.executerheader持续时间小于SQL分析器批处理持续时间



如何调用SqlCommand。ExecuteReader需要比SQL批处理本身更少的时间来完成,如SQL Profiler中所见?

我有以下简单的代码运行在一个控制台应用程序调用SqlCommand。ExecuteReader,使用Stopwatch对象计时:

var swQueryTime = new Stopwatch();
        var conn = new SqlConnection("Data Source=.;Initial Catalog=master;Trusted_Connection=True;");
        conn.Open();
        string sql = string.Format(@"select * from sys.dm_os_memory_clerks; select * from sys.dm_os_performance_counters ");
        for (int i = 0; i < 10; i++)
        {                
            var comm = new SqlCommand(sql, conn);
            swQueryTime.Restart();
            var dr = comm.ExecuteReader();
            swQueryTime.Stop();
            Console.WriteLine("ElapsedMilliseconds: {0}", swQueryTime.ElapsedMilliseconds);
            dr.Close();
            comm = null;
        }

SQL批处理的平均持续时间是。net端报告的4倍。

我已经检查了profiler是专门报告毫秒。

我没有使用SqlCommand.ExecuteReader的异步版本。

探查器持续时间不是我读取并使用探查器开始和结束时间验证的多个线程/内核的所有时间之和。

想法赞赏。

因为您只能计时到批处理的最开始。如果您也使用数据,时间可能会对齐:

using(var dr = comm.ExecuteReader()) {
    do {
        while(dr.Read()) {}
    } while (dr.NextResult());
}

顺便说一下,还有一些SET选项可以改变某些查询的性能——不确定这里是否适用,但它可以显著影响具有计算+持久化值的表:如果CC_2值与创建列时的设置不兼容,则需要重新运行逐行计算。如果要对计算+持久化+索引列进行过滤,这一点尤其值得注意——它必须执行表扫描(或类似操作),而不是索引扫描/索引查找。

最新更新