我有一段将数据导入sql表的代码。当输入数据出现问题(例如,数据类型错误或将被截断)时,它会按预期生成异常,但速度非常慢。如果它们都很好,我可以在几秒钟内导入10,000行,但有时源数据需要一点tlc,因此应用程序会导入好行并报告异常,以便可以修复它们。例如,如果所有10,000行都有一个需要缩短的字段,因为它会被截断,那么它需要10分钟而不是10或20秒。
增加的时间不是因为任何代码在catch块中运行...即使catch块中根本没有代码也会这样做。任何人都知道这是否就是它的方式,或者是否有任何可以做的事情让它更快?
编辑:好的,根据请求,我在下面添加了一些代码,但我想您很快就会明白为什么我认为最初没有必要这么做:)
public void ImportRow(DataRow r, SqlConnection conn, SqlTransaction trx)
{
var sqlCmd = _importCommand.CreateSqlCommand(r);
SqlCommand sCom = new SqlCommand(sqlCmd, conn, trx);
try
{
sCom.ExecuteNonQuery();
}
catch (Exception e)
{
}
}
_importCommand.CreateSqlCommand(r)
只返回一个字符串(正如您在SqlCommand
构造函数参数中使用它所推断的那样)。正如您所看到的,我还没有向catch块添加任何代码。当没有异常时,它会非常快地执行sCom.ExecuteNonQuery();
,但是当有异常时会有短暂停顿。 ImportRow
方法在来自另一个函数的循环中调用,但我确实将滞后标识为来自此方法的try块,因此其他代码不相关。
答案 0 :(得分:6)
在批量插入操作期间遇到错误时,必须回滚成功插入的记录。根据经验,与撤消操作相比,回滚期间操作的撤消将始终较慢,因为它必须回读日志(针对写入而非针对读取进行优化)和补偿操作。然而,不能用10秒到10分钟来解释。因此,除非你能提供某种服务器需要10分钟的证据,否则我必须得出结论,那就是那些为这10分钟做某事的应用程序代码。
<强>更新强>
让我们尝试所有失败的10k插件,并将它们与成功的10k插件进行比较:
set nocount on;
use master;
if db_id('test') is not null
begin
alter database test set single_user with rollback immediate;
drop database test;
end
go
create database test;
go
use test;
go
create table good (a int, b char(1000));
go
declare @start datetime = getdate(), @i int =0;
begin transaction;
while @i < 10000
begin
insert into good (a) values (@i);
set @i += 1;
end
commit;
declare @end datetime = getdate();
select 'good: ', datediff(ms, @start, @end);
go
create table bad (a int, b char(1000), constraint fail check (a<0));
go
declare @start datetime = getdate(), @i int =0;
begin transaction;
while @i < 10000
begin
insert into bad (a) values (@i);
set @i += 1;
end
commit;
declare @end datetime = getdate();
select 'bad: ', datediff(ms, @start, @end);
go
在我的测试机器上,我获得了大约600毫秒的“好”情况和大约1400毫秒的坏情况。所以例外情况加倍,但几乎没有时间。
接下来,让我们做同样的事情,但是来自托管客户端:
static void Main(string[] args)
{
try
{
using (SqlConnection conn = new SqlConnection(@"..."))
{
conn.Open();
Stopwatch sw = new Stopwatch();
sw.Start();
using (SqlTransaction trn = conn.BeginTransaction())
{
SqlCommand cmd = new SqlCommand(
"insert into good (a) values (@i)", conn, trn);
SqlParameter p = new SqlParameter("@i", SqlDbType.Int);
cmd.Parameters.Add(p);
for (int i = 0; i < 10000; ++i)
{
p.Value = i;
cmd.ExecuteNonQuery();
}
trn.Commit();
sw.Stop();
}
Console.WriteLine("Good: {0}", sw.Elapsed);
int excount = 0;
sw.Reset();
sw.Start();
using (SqlTransaction trn = conn.BeginTransaction())
{
SqlCommand cmd = new SqlCommand(
"insert into bad (a) values (@i)", conn, trn);
SqlParameter p = new SqlParameter("@i", SqlDbType.Int);
cmd.Parameters.Add(p);
for (int i = 0; i < 10000; ++i)
{
p.Value = i;
try
{
cmd.ExecuteNonQuery();
}
catch (SqlException s)
{
++excount;
}
}
trn.Commit();
sw.Stop();
}
Console.WriteLine("Bad: {0} [Exceptions: {1}]",
sw.Elapsed, excount);
}
}
catch (Exception e)
{
Console.WriteLine(e);
}
}
结果(零售版和调试版都有相似的时间):
Good: 00:00:00.8601303
Bad: 00:01:57.8987760 [Exceptions: 10000]
因此,从原始SQL Server时间的1.4秒开始,时间已经过去了将近2分钟。所以案件结案,例外是昂贵的,对吗?没那么快。尝试运行应用程序不连接调试程序(Ctrl + F5):
Good: 00:00:00.6640281
Bad: 00:00:02.3746845 [Exceptions: 10000]
回到2秒。所以真正的罪魁祸首不是SQL Server,不是C#异常处理也不是SqlClient层。是调试器。这是正常的,因为调试器会执行一些非常具有侵入性的操作,并在每个抛出的CLR异常上运行大量代码。如果您的代码基本上只是抛出异常,那么结果会产生很大的影响。它被称为First Chance Exception Handling和other have said it before。
但是,如果正在调试应用程序,则调试器会查看所有内容 程序之前的异常。这是区别 第一次和第二次机会异常:调试器得到第一个 有机会看到异常(因此得名)。如果调试器允许 程序执行继续并且不处理异常, 该程序将像往常一样看到异常。
再次证明,在处理性能问题时,最好是衡量。
答案 1 :(得分:2)
如果您在客户端上执行相同的检查,您将能够快速报告那些找到好记录的人,并快速报告错误。
您可以动态推断您要编写的表的布局,以便需要复制表格布局规范,但我认为除非您的组件本质上非常通用,否则值得烦恼。
答案 2 :(得分:0)
一些提示:
MERGE
和OPENROWSET
是我目前最喜欢的跨平台乐趣) - 它们是很多比使用单个更新/插入语句更快。答案 3 :(得分:0)
异常会导致如此大的减速似乎很奇怪,除非你当然回滚了交易,在这种情况下我完全可以理解问题的缓慢。
无论如何,您可以尝试的一件事是从表定义中推断出列的长度,并截断数据PRIOR以插入数据库。因此,您只会插入好的数据。
答案 4 :(得分:0)
异常是缓慢的,因为在投掷和捕获时,需要完成大量的簿记,这些都是最终确定需要执行的所有堆栈帧计算,这通常需要更长的时间。我不认为你可以通过使用一些内置的方法来加速这一点。
您必须自己运行检查而不是SQL才能返回错误。我知道这有点乏味,但没有办法加速。
另一种选择是在并行线程中插入行。这将加快速度,因为一行中的异常不会减慢所有挂起的行。