Question

我有一段将数据导入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块，因此其他代码不相关。

Answer 1

在批量插入操作期间遇到错误时，必须回滚成功插入的记录。根据经验，与撤消操作相比，回滚期间操作的撤消将始终较慢，因为它必须回读日志（针对写入而非针对读取进行优化）和补偿操作。然而，不能用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。

但是，如果正在调试应用程序，则调试器会查看所有内容程序之前的异常。这是区别第一次和第二次机会异常：调试器得到第一个有机会看到异常（因此得名）。如果调试器允许程序执行继续并且不处理异常，该程序将像往常一样看到异常。

再次证明，在处理性能问题时，最好是衡量。

Answer 2

如果您在客户端上执行相同的检查，您将能够快速报告那些找到好记录的人，并快速报告错误。

您可以动态推断您要编写的表的布局，以便需要复制表格布局规范，但我认为除非您的组件本质上非常通用，否则值得烦恼。

Answer 3

一些提示：

创建一个参数化查询prepare并重复使用它。这样，SQL Server可以缓存执行计划
如果您要导入大量数据，请使用bulk import功能（MERGE和OPENROWSET是我目前最喜欢的跨平台乐趣） - 它们是很多比使用单个更新/插入语句更快。

Answer 4

异常会导致如此大的减速似乎很奇怪，除非你当然回滚了交易，在这种情况下我完全可以理解问题的缓慢。

无论如何，您可以尝试的一件事是从表定义中推断出列的长度，并截断数据PRIOR以插入数据库。因此，您只会插入好的数据。

Answer 5

异常是缓慢的，因为在投掷和捕获时，需要完成大量的簿记，这些都是最终确定需要执行的所有堆栈帧计算，这通常需要更长的时间。我不认为你可以通过使用一些内置的方法来加速这一点。

您必须自己运行检查而不是SQL才能返回错误。我知道这有点乏味，但没有办法加速。

另一种选择是在并行线程中插入行。这将加快速度，因为一行中的异常不会减慢所有挂起的行。

Sql异常非常慢......如何加速？

5 个答案: