gpt4 book ai didi

sql-server-2005 - 为什么 SQLCLR proc 运行速度比相同的代码客户端慢

转载 作者:行者123 更新时间:2023-12-04 07:07:38 27 4
gpt4 key购买 nike

我正在编写一个存储过程,完成后将用于逐列扫描临时表以查找虚假数据。

练习的第一步只是扫描表格——这就是下面的代码所做的。问题是此代码在 5:45 秒内运行 --- 但是作为控制台应用程序运行的相同代码(当然更改连接字符串)在大约 44 秒内运行。

    using (SqlConnection sqlConnection = new SqlConnection("context connection=true"))
{
sqlConnection.Open();
string sqlText = string.Format("select * from {0}", source_table.Value);
int count = 0;
using (SqlCommand sqlCommand = new SqlCommand(sqlText, sqlConnection))
{
SqlDataReader reader = sqlCommand.ExecuteReader();
while (reader.Read())
count++;
SqlDataRecord record = new SqlDataRecord(new SqlMetaData("rowcount", SqlDbType.Int));
SqlContext.Pipe.SendResultsStart(record);
record.SetInt32(0, count);
SqlContext.Pipe.SendResultsRow(record);
SqlContext.Pipe.SendResultsEnd();
}
}

然而,相同的代码(当然不同的连接字符串)在大约 44 秒内在控制台应用程序中运行(这更接近我在客户端的预期)

我在 SP 方面缺少什么,这会导致它运行如此缓慢。

请注意:我完全理解,如果我想要行数,我应该使用 count(*) 聚合 --- 这不是本练习的目的。

最佳答案

您正在编写的代码类型极易受到 SQL 注入(inject)的影响。您可以使用 RecordsAffected 属性来查找阅读器中的行数,而不是像您一样处理阅读器。

编辑:

在做了一些研究之后,您看到的差异是上下文连接和常规连接之间的设计差异。彼得·德贝塔(Peter Debetta)对此发表了博客并写道:

“上下文连接是这样编写的,它一次只获取一行,因此对于 2000 万个奇数行中的每一行,代码分别要求每一行。然而,使用非上下文连接,它请求 8K一次行。”

http://sqlblog.com/blogs/peter_debetta/archive/2006/07/21/context-connection-is-slow.aspx

关于sql-server-2005 - 为什么 SQLCLR proc 运行速度比相同的代码客户端慢,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/883407/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com