C# 频繁对数据库操作，性能问题

 C# 频繁对数据库操作，性能问题

1、与数据库交互，创建一次连接，必然影响性能。

Connection.open(); 打开以后用完关闭Connection.close();就算你只打开一次连接，用过多以后，再close；

性能会比前者快很多倍，如果只有100条数据以内，那也过得去；如果数据量达到1000,那这样性能也提升不上来；

Select、Insert、Update等语句，字符串连接起来，做一次执行。效率要可观多了。如下：

command.Excu(Insert into Table(a,b,c)Values(1,2,3);Insert into Table(a,b,c)Values(1,2,3);Insert into Table(a,b,c)Values(1,2,3););

 

2、SqlBulkCopy

在做大批量数据插入的时候，如果用Insert into ... values (...)这种方式的话效率极低，批量插入方法。

private static long SqlBulkCopyInsert() 
{ 
Stopwatch stopwatch = new Stopwatch(); 
stopwatch.Start(); 
DataTable dataTable = GetTableSchema(); 
string passportKey; 
for (int i = 0; i < count; i++) 
{ 
passportKey = Guid.NewGuid().ToString(); 
DataRow dataRow = dataTable.NewRow(); 
dataRow[0] = passportKey; 
dataTable.Rows.Add(dataRow); 
} 
SqlBulkCopy sqlBulkCopy = new SqlBulkCopy(connectionString); 
sqlBulkCopy.DestinationTableName = "Passport"; 
sqlBulkCopy.BatchSize = dataTable.Rows.Count; 
SqlConnection sqlConnection = new SqlConnection(connectionString); 
sqlConnection.Open(); 
if (dataTable!=null && dataTable.Rows.Count!=0) 
{ 
sqlBulkCopy.WriteToServer(dataTable); 
} 
sqlBulkCopy.Close(); 
sqlConnection.Close(); 
stopwatch.Stop(); 
return stopwatch.ElapsedMilliseconds; 
}  

 

 

　　使用SqlBulkCopy类进行数据插入其原理是采用了SQL Server的BCP协议进行数据的批量复制。这里我们先要建好一个DataTable（最好是通过DataAdapter来灌数据得到，因为这样出来的DataTable就已经有跟数据表相同的列定义，可以免去之后Mapping Column的步骤），把要插入的数据加进这个DataTable中，然后用SqlBulkCopy的实例来插入到数据库中。经过测试，SqlBulkCopy方法比直接用Sql语句插入数据的效率高出将近25倍。

 

　　另外批量导入SQL、MYSQL等数据是同样的for循环，使用拼出来的sql或者使用参数的方式传递或者使用事务等不同方式的传递效率都不同。如果不使用SqlBulkCopy的方式的话，我测试下来做快递是用一次事务来操作为最快。因为10000次的循环如果是每次提交，那么都有链接和停止数据库的操作，或者说他包含了1000次的小事务处理。如果外面就一个事务的话效率肯定会高。

 

其它方案网上参考:

技术方案一：

利用数据库访问类调用存储过程，利用循环逐条插入。很明显，这种方式效率并不高。

技术方案二：

由于是考虑到大数据量的批量插入，于是想到了ADO.NET2.0的一个新的特性：SqlBulkCopy。有关这个的性能，很早之前我亲自做过性能测试，效率非常高。这也是我推荐的技术方案。

技术方案三：

利用SQLServer2008的新特性--表值参数（Table-Valued Parameter）。表值参数是SQLServer2008才有的一个新特性，使用这个新特性，我们可以把一个表类型作为参数传递到函数或存储过程里。不过，它也有一个特点：表值参数在插入数目少于 1000 的行时具有很好的执行性能。

技术方案四：

对于单列字段，可以把要插入的数据进行字符串拼接，最后再在存储过程中拆分成数组，然后逐条插入。查了一下存储过程中参数的字符串的最大长度，然后除以字段的长度，算出一个值，很明显是可以满足要求的，只是这种方式跟第一种方式比起来，似乎没什么提高，因为原理都是一样的。

技术方案五：

考虑异步创建、消息队列等等。这种方案无论从设计上还是开发上，难度都是有的。

优势对比：

方案一的效率最低，需要多次更新数据库，方案四与方案一原理相同，只是将处理放到了存储过程中，且在参数传入前后需进行拼接和拆分，操作比较麻烦。用SQL2008数据库时推荐使用方案四。

对比方案一、二、三，技术方案二的优势还是蛮高的。无论是从通用性还是从性能上考虑，都应该是优先被选择的，另外它的技术复杂度要比技术方案三要简单一些，设想我们把所有表都创建一遍表值类型，工作量还是很大。

因此推荐大家使用第二种技术方案。