ADO.NET 老牛拉车??

Question

最近饶有兴致的修改了一个小程序，结果出乎以外。
程序业务逻辑比较简单，把这个文本文件中数据更新到数据库中，中间还包含了一些字符串解析、数据计算等过程。这个文本文件大小为200多M，记录条数为70多万条。
原来的程序是用c++/MFC开发的，数据库连接采用odbc方式。
伪代码大致如下：
先SQLPrepare创建更新语句，SQLBindParameter绑定参数，SQLExecute执行语句。
这样处理下来一般10分钟左右可以处理完成。现在推出.net 2.0，在VS.net 2005用C＃重新编写了以上小程序。
界面是弄的华丽了。但是效率老牛一样，1000条都没更新完成已经耗去我1分多钟。
我去掉数据库更新部分代码，对于文件及字符串处理，效率还可以，为什么以下代码效率会如此低下？
现在是每条记录都调用如下函数，sql语句根据参数生成。 SqlCommand command = null;            try
            {
                command = conn.CreateCommand();
                command.CommandText = "...";
                command.CommandType = CommandType.Text;                return command.ExecuteNonQuery();
            }
            catch (SqlException e)
            {
                //...
            }
是否有啥好方法能够提高执行效率？

Answer 1

使用ado.net肯定会比odbc慢，这是必然的。个人觉得2.0比1.1能吃资源。

Answer 2

但是我看到你的对比时间有些离谱。odbc:70多万条, 10分钟
ado.net:1000条，1分钟多我虽没做过类似的测试，但觉得不会慢得这么多。

Answer 3

to Knight94(愚翁) 
我也很诧异。我之前的方法是只创建一次preparestatement，然后根据参数变化，执行execute语句。
而在ado。net中我没有找到PrepareStatement，所以每更新一条记录都去创建command，
是不是这个有关系？

Answer 4

to 我之前的方法是只创建一次preparestatement，然后根据参数变化，执行execute语句。
而在ado。net中我没有找到PrepareStatement，所以每更新一条记录都去创建command，
是不是这个有关系？哦，你每次都是新建command，为什么不用同一个command呢，只是修改command参数的值呢，然后去执行呢

Answer 5

sample code as follows:try
{
sqlConn.Open();//Connect to sql server
}
catch( Exception err )
{
MessageBox.Show( err.Message );
return;
}SqlCommand myCommand = new SqlCommand( "UpdateEmployee" );
myCommand.Connection = sqlConn;
myCommand.CommandType = CommandType.StoredProcedure;
//Set parameters
myCommand.Parameters.Add( "@EmployeeName", 
SqlDbType.VarChar, 20 );
myCommand.Parameters.Add( "@Password", 
SqlDbType.VarChar, 20 );
myCommand.Parameters.Add( "@Description",
SqlDbType.VarChar, 255 );for( int i = 0; i < 5; i++ )
{
// Update parameters value
myCommand.Parameters["@EmployeeName"].Value = DateTime.Now.Ticks.ToString();
myCommand.Parameters["@Password"].Value = DateTime.Now.Ticks.ToString();
myCommand.Parameters["@Description"].Value = DateTime.Now.Ticks.ToString();
myCommand.ExecuteNonQuery();
System.Threading.Thread.Sleep( 5 );
}// Release resources
myCommand.Dispose();
sqlConn.Close();

Answer 6

你可以把上面for循环中的抽出来做成函数即可。

Answer 7

ADO.NET推荐做法：首先创建一个CustomTextParser把文本文件Parse成DataTable，
然后再用SqlDataAdapter把这个DataTable给更新到数据库中去。想要效率高就按上面那样做。
每一条记录都去创建一个SqlCommand对象实在是太恐怖了，我怀疑主要的开销会是内存分配和垃圾回收……

Answer 8

to 首先创建一个CustomTextParser把文本文件Parse成DataTable，
然后再用SqlDataAdapter把这个DataTable给更新到数据库中去。我倒不赞同，70m的文件，都解析到DataTable，那得多大。

Answer 9

不好意思，没看到文件大小。不过可以分部分Parse^

Answer 10

其实我发现楼主的一定是速度最快的；Knight94(愚翁)等的做法用DATATABLE等是不明智的选择，因为给DATATABLE等赋值需要额外的系统开销；我看过ADO反编译代码；你们上面的所有方法最后都要由类转换为SQL语句；
楼主系统慢的主要原因在打开文件时可能是一次把200都读出来；时间消耗在内存申请上了；一次最大读100条数据；
把你的代码改为
 SqlCommand command = null;            try
            {
                command = conn.CreateCommand();
                command.CommandText = "insert into ..... insert into   ";//xia写一百个insert into 语句。
                command.CommandType = CommandType.Text;                return command.ExecuteNonQuery();
            }
            catch (SqlException e)
            {
                //...
            }
不服的可以根我的方法PK一下。

Answer 11

ADO.NET/SQL SERVER 有没有什么比较底层的 SQL 执行函数, 能够直接执行一段 SQL 文本命令而不用创建 command, adapter 之类的中间过程 ?

Answer 12

to 我一直在寻找首先你没有看清我给的方法，建议你仔细看我的回复；第二，你的方法要快吗，符合实际要求吗，我觉得不见得，
且不说一百条拼接的Insert语句是否正确与否，光是拼接一百条Insert语句就够累得，还有你是否考虑到CommandText的长度限制，以及SQL语句的字符限制等等。你这样的代码可读性差，调试和维护都很麻烦。看了你的回复，我不禁想问一句，你是程序员吗？

Answer 13

忘记了一件事情, 实践出真知, 其实楼主可以自己写几个计时的测试语句, 插入到相关命令行附近, 看看对比 ODBC 到底哪个慢, 到底是是 conn.CreateCommand 这一步拖了速度还是 ExecuteNonQuery 拖了速度, 等等.

Answer 14

再多说两句（希望不要有人嫌我啰嗦）很多人用.net写程序，对.net中的一些com或者类不是很了解，因此在程序某些细节处理上处理不当，而会造成错误或者效率低的情况发生，这对于每个人来说，都是存在的，毕竟不是每个人对一个工具从一开始就能很熟练的使用。对于这种失误或者称为技术上的缺陷，会随着使用次数增加或者技术交流等方式，就能弥补过来。但是还有一种，是很难纠正过来的，就是编码习惯，没错，我们是程序员，但不能为了写程序而写程序。一段代码不光是为了实现某种功能，还要考虑到后期的测试以及维护等等，如果是oop的话，考虑的因素会更多。因此作为一个程序员，可怕的不是前者，而是后者。

Answer 15

有时候你看起来很愚笨的方法（比如可读性差，难以维护），其实是解决问题的最佳方案。就像很常见的一个问题：从数据库中取某个父节点的所有子节点集合。难道一定要递归的从数据库中不停的用递归SqlDataAdapter来取数据吗？我看就不见得。如果层次少，子节点不多。没关系`。如果是一个庞大的产品库。是一个上100万个节点的层次树。我想你的应用程序和数据库都会OVER。这种情况用存储过程 不见得就是坏事（你可能又会说难以维护等等道理），哈哈

Answer 16

各有各的理。主要是看具体情况而来。像楼主这种情况，其实根本就没有说清楚。
如果经常要把一个文本文件导入到数据库，还是推荐Parse成DataTable或者Parse成SqlCommand来做。如果因为这样而导致速度慢，则解决方案还有很多，例如开后台线程分批慢慢处理。
如果只是要弄一次两次，根本就用不着写程序，直接用SqlServer的导入导出程序就成。直接Parse成SqlText的确是可以达到很高的效率，但再快也快不过直接导入。

Answer 17

代码性能太差，每条记录创建一个IDataCommand对象?？？
我同意渔翁的做法，多条记录作数据操作，一定要避免重复创建操作对象，包括数据连接的打开关闭，都尽量一次完成，否则效率自然会底下.
渔翁的方式效率是比较高的.to 我一直在寻找() ( ) 信誉：96 :
你的代码太业余了，自己多练练再出来讨论吧,还说你的效率最高？？呵呵

Answer 18

SQL语句的长度是有限制的，70W条连成一句，那还怎么执行啊？

Answer 19

每次都实例化一个SqlCommand?? 太可怕~~~...

Answer 20

实例化command是一个原因，另外一个比较主要的原因应该是try{}catch{}吧？

Answer 21

说白了ADO.NET本身就不适合用于大批量数据导入。但现实中大批量数据导入没几个用ADO.NET。

Answer 22

RE:EmotionalIntelligenc(听海(廷海)) 
的确没有试验过；用的是感觉；我们可以测试测试。

Answer 23

asp.net(c#)技术交流  18590648

Answer 24

这方面 PHP/MySQL 做得还不错, 用 Insert 导入两三百 M 的数据大概也就 10 来分钟. 怀念 ..

Answer 25

RE:Knight94(愚翁) 
你看过ADO的底层吗？没有，你一定没有；你知道ADO是怎么实现的吗。你不知道。
我告诉你，我看过，我反编译后看的；ADO给你提供的所有类最后都会生成SQL语句；ADO发送给服务器的也是SQL语句(我用网卡侦听器侦听过)；你通过使用ADO提供的类来操作；不就是多一层操作。
再告诉你：Knight94(愚翁)；我上CSDN的时候你还没毕业呢；我用C、C＋＋操作ODBC底层API的时候你可能还不知道什么叫ADO呢；别看你3颗星，就用这种口气跟我说话，我其实不想跟你比什么，我告诉你我现在的确不是程序员了，我是一个软件公司的经理公司不大，每年利润差不多90万。我以前是在社区中“长大”的，我必须多逛逛社区，好好帮助我们的弟弟妹妹，可能太忙，回答的问题有限，所有星数比你低。Knight94(愚翁)别这样，别以为自己特L B要知道山外有山，我感觉我自己就挺一般的。只是机遇好点。Knight94(愚翁)多多看看底层的东西吧，对你一定有好处的，别以为自己会用.Net的类就是高手；牛人。
不好意思，说得多了点。

Answer 26

其实“zhongkeruanjian(编程亮子) ”说得对，我们这个贴子的前提是速度；我们都知道许多时候在“空间”、“时间”、“速度”、“可维护性”、“产量”中间找一个平衡点的。其实用我的方法可读性不一定不好；只是你可能不习惯。

Answer 27

RE:Kshatriya(\r\n\b) ( ) 信誉：99 
兄弟，你说我的方法太业余；是不是只用.Net类才教专业呢。搞笑，是不是用汇编的、C、C++、那就更加业余了。自己不会写SQL语句，不会底层的操作就说别人业余，悲哀、真的特悲哀。

Answer 28

to: 我一直在寻找() 
看了你的发言大吃一惊，也许你底层东西操作比较多罢了，也没什么特别,你自己用汇编写个类ODBC出来用，我想完全没有必要。并且从你的语句中感觉你却实只是在小公司呆过，如果你的用户同时有几千台机在用你的C/S程序，保证你会觉得可维护性，稳定性远远大于效率。用ado和ODBC相比也不可能相差很大，否则微软的东西还有人用，他们的程序员当然也不是吃白饭的？

Answer 29

还是不要吵了，不然成了水贴了。哈。看看能用最好的方法提高性能吧。刚才看到一个，不知道速度会怎么样？ 谁用过这个没有？性能怎样`？
SqlConnection connection = New SqlConnection(connectionString);
string queryString =  "BULK INSERT Northwind.dbo.[Order Details] " +
    "FROM 'f:\mydata\data.tbl' " +
    "WITH ( FORMATFILE='f:\mydata\data.fmt' )";
connection.Open();
SqlCommand command = new SqlCommand(queryString, connection);command.ExecuteNonQuery();
connection.Close();
还有NET2.0里已经有个SqlBulkCopy类，专用于批量复制的

Answer 30

to 我一直在寻找
   
   重新造轮子有意思吗？....
   有本事微软咋不叫你去写ADO.NET？？...
   
   大家都是来学习的.....以和为贵

Answer 31

引用楼上某位发言: "也许你底层东西操作比较多罢了，也没什么特别,你自己用汇编写个类ODBC出来用，我想完全没有必要。并且从你的语句中感觉你却实只是在小公司呆过
 ....
保证你会觉得可维护性，稳定性远远大于效率
....
用ado和ODBC相比也不可能相差很大，否则微软的东西还有人用，他们的程序员当然也不是吃白饭的".感觉这位仁兄没怎么接触过 OLTP 系统, 一棍子把人打死了. 在一个大型 OLTP 中没有效率搞不好你的程序刚运行 3 秒钟就服务器当机了, 这时候你还谈什么可维护性和稳定性 ? 电信的计费系统怎么做出来的 ? 难道是用 ado 做出来的 ? google 的核心服务器用的不是 ibm 也不是 hp 而是自己开发的. 难道 ibm, hp 是垃圾, 他们的工程师都是吃白饭的 ? 又或者 google 是小公司 ?另对阁下的如下高论: "ado 和 odbc 的差别不可能相当大". 本人敬仰之情犹如黄河之水 .....

Answer 32

" 重新造轮子有意思吗？....
   有本事微软咋不叫你去写ADO.NET？？..."
这不是有没有意思的问题；我想对你说我这段时间重写了WebService的实现，在你看来可能也是“重新造轮子”；我想对你说我重写WebService的的原因是因为他有许多地方我使用不方便；比如不支持事件；WebService在客户端调用不是特别灵活。。
有时候“重新造轮子”是有必要的，SUN27战斗机那么好用为什么我们还要造歼10，因为如果不造歼10我们就造不出来歼14。

Answer 33

to 我一直在寻找:
首先对我那句粗鲁的回复道歉，说"业余"这话就有些太幼稚了.就事论事，我们来看渔翁的代码，我不知道哪里用到了DataTable,为什么把DataTable牵扯到里面来了？
关于大量数据的操作，我不是行家，但是也是作过一些的，参数化查询无疑是一个好方法,而拼接长sql，性能未必就比循环执行要快.而且在项目里面灵活性，扩展，维护难度都是个问题.
另外在mysql里面试试长sql,会死人的.DataTable似乎是lvony提出来的，用这个，我也是很不赞同，所以，上面的争论似乎完全是场误会.大家的目的都是探讨问题，虽然真理需要辩论，但是争论过于激烈也不好了

Answer 34

其实我的看法和渔翁的基本相同，楼主的问题似乎就是出在重复创建对象上面.
下面的这三句,
command = conn.CreateCommand();
command.CommandText = "...";
command.CommandType = CommandType.Text;command = conn.CreateCommand();
command.CommandType = CommandType.Text;
这两句只要写一次就够了.不用每条记录作一次，这相当于重复作了70W次重复操作.
还有就是参数化查询，效率明显高于直接执行SQl,不信的可以测试一下.

Answer 35

我一直在寻找() ( ) 信誉：96  2006-05-04 18:30:00  得分: 0  
 
 
   " 重新造轮子有意思吗？....
   有本事微软咋不叫你去写ADO.NET？？..."
这不是有没有意思的问题；我想对你说我这段时间重写了WebService的实现，在你看来可能也是“重新造轮子”；我想对你说我重写WebService的的原因是因为他有许多地方我使用不方便；比如不支持事件；WebService在客户端调用不是特别灵活。。
有时候“重新造轮子”是有必要的，SUN27战斗机那么好用为什么我们还要造歼10，因为如果不造歼10我们就造不出来歼14。
 
 
嗯，如果真是这样，那我真的太佩服你了..重写webservice..高人

Answer 36

主要是可维护性差了
可维护性绝对至上这个也是Java和.NET兴起之后的一种理论,可是.NET还是保留了Goto.可以试试BULK INSERT

Answer 37

为了给大家来点实际的；我们来比对某个东西操作用什么方法速度最快；比如向数据库插入数据用什么方法最快；比如不同计算机间进行通讯用什么方法最快。
   我们比的是方法，用什么语音都无所谓VB.Net、C#、j#、C++(托管代码)，最好别用IL，毕竟这中方法在项目中不太实用。
  我先开一个目录贴，什么叫目录贴呢，就是在本贴中只讨论要操作的东西，然后再对每一个具体要讨论的内容开一个帖子。
  希望大家给个面子，多多灌水。
请大家先去：http://community.csdn.net/Expert/topic/4730/4730832.xml?temp=.8603479
我等着大家。

Answer 38

一次性执行多条语句（insert语句），固然是最好的，不过有点担心commandtext的长度限制。另外如果自己写Sql语句，那也只能适用对文本的操作，不够通用。有些时候我要操作的对象包括二进制这种大对象，这样写Sql语了就变得不方便了。

Answer 39

我感觉你应该去试试微软提供的Microsoft Enterprise Library!里面主要是对数据库操作的，应该是最优的语句了，看能不能解决你的问题。在微软官方网站上可以下载的!

Answer 40

控制最少的实例，你在不停的实例化SqlCommand，你没有搞多线程，没有这个比较。
使用SqlDataAdapter来管理数据的更新访问。
另外，可以修改成存储过程代替sql 字符串。

Answer 41

怎么都是批判  我一直在寻找() 的??
个人对Knight94(愚翁) 的提法不敢苟同.  如果是我,咱先不说代码如何,从实现方法上我是会用我一直在寻找() 的那种方式.

Answer 42

我那种方式有个地方需要改一下SQL语句别用String类型用StringBuilder；为了达到最好的性能可以先估算一下100条记录的总长度；避免StringBuilder反复申请内存。我试验了一下在String拚接时性能能提高500％，（只在拚接时）

Answer 43

给段代码大家看看
这是给铁通做的一个导出数据到Execel的其中一段代码
导出300M的文件用时45分钟左右,不知算快还是慢
在这里我就用了大量的insert sql 语句
这些insert sql 语句我先用arrInsert 数组存起来
private void CreateRecord() 
{
string onnection  "Provider=Microsoft.Jet.OleDb.4.0;Data Source="+strFilePath2Name;
OleDbConnection conn = new OleDbConnection(connection);
conn.Open();
OleDbCommand cmd = new OleDbCommand();
foreach(string insert in arrInsert)
{
cmd = new OleDbCommand(insert,conn);
cmd.ExecuteNonQuery(); }
conn.Close();
conn =null;

}

Answer 44

如果你的用户同时有几千台机在用你的C/S程序，保证你会觉得可维护性，稳定性远远大于效率。
--------------------不見得 當並發量太大時首先要考慮的是性能 跑都跑不動你還奢談什麽穩定、可維護（除非你要的是一動不動的“穩定”和因此完全不需要維護的結果） QQ的並發數大不大？人家就用原生代碼（看他招的人就知道），按照你的理論是十惡不赦了。

Answer 45

kinthtime(中关一杰) ( ) 信誉：100  2006-05-08 21:48:00  得分: 0  
 
 
   给段代码大家看看
这是给铁通做的一个导出数据到Execel的其中一段代码
导出300M的文件用时45分钟左右,不知算快还是慢
在这里我就用了大量的insert sql 语句
这些insert sql 语句我先用arrInsert 数组存起来这段代码肯定慢了，DBCommand对象没有必要每次循环创建一次

Answer 46

。。
性能的问题一般是多方面的 
但是这个问题明显主要是对象反复创建导致，再一个就是数据库的连接要保持打开直到所有的数据都提交完，典型的例子就是微软建议用StringBuilder在频繁造作的字符串中代替string，就是避免对象反复创建。
我一直在寻找 说得方法我觉着没必要。渔翁的做法比较好。
再就是 我一直在寻找 动不动就地层，但是水平确实不怎么样。

Answer 47

command = conn.CreateCommand();
我想楼主最好不要每次执行都这样做,把它们单独出来,只create一次,每次再赋值给参数,再excute,这样效率会高一点吧,

Answer 48

一些问题＆想法：
1、1000条/分和7w+条/分是只纯粹的数据库操作消耗时间的比较还是整个程序消耗时间的比较？楼主能确定程序的瓶颈一定是在贴出的这段代码里面吗？这个结论是出自直觉还是用某种的分析方法和工具得出呢？2、就这段代码而言，在循环内部使用conn.CreateCommand()对执行效率会有影响。下面是我的3段代码，供参考。第一段，在循环外初始化SqlCommand：
// 假设insert语句有2个参数，第一个是整数，第二个是长度为100的nvarchar
const string Param1 = "@p1";
const string Param2 = "@p2";string insertStatement = GetInsertStatement (Param1, Param2);
System.Data.SqlClient.SqlCommand command = new System.Data.SqlClient.SqlCommand (insertStatement, conn);command.Parameters.Add(Param1, SqlDbType.Int);
command.Parameters.Add(Param2, SqlDbType.NVarChar, 100);
command.Prepare ();第二段，循环体：
// 导入记录
command.Parameters[Param1] = value1;
command.Parameters[Param2] = value2;
command.ExecuteNonQuery();第三段，第一段代码中用到的GetInsertStatement方法：
private string GetInsertStatement(string param1, string param2)
{
    return string.Format("Insert into table (f1, f2) values ({0}, {1})", param1, param2);
}

Answer 49

我用.net导入数据库700多万条(95M)只用40多秒，用BULK INSERT,建表，导入数据，设索引一次完成的。没有做什么计算。
导出文本文件２５０万条左右１５－２０秒左右，没有尝试过一次导出更多的，不过我觉得也不会太慢。经常操作的数据量在５０－－３００万也从来没有超过一分钟的。

Answer 50

command.CommandText = "insert into ..... insert into   ";//xia写一百个insert into 语句。
光这个写100个语句我就不赞同,把人已经给累死了

Answer 51

关键是找到解决问题得方法，比如bulk insert, dbcommand对象得创建问题
管别人编码风格什么事......

Answer 52

楼上争论的精彩啊，让我看了欲罢不能！佩服佩服！
to: kinthtime(中关一杰) 
你的代码为什么不这样写呢？
private void CreateRecord() 
{
string onnection  "Provider=Microsoft.Jet.OleDb.4.0;Data Source="+strFilePath2Name;
OleDbConnection conn = new OleDbConnection(connection);
conn.Open();
OleDbCommand cmd = new OleDbCommand();
                           cmd.Connection = conn;
foreach(string insert in arrInsert)
{
cmd.CommendText = insert;
cmd.ExecuteNonQuery(); }
conn.Close();
conn =null;

}
个人觉得这样会好一些吧？谢谢赐教！

Answer 53

提出的各种意见和看法,不知道大家有无实际做过测试?1):Command创建问题
我对使用Command的两种方式(一次创建,循环使用 & 每次创建和使用)进行了Insert操作对比测试,发现完全是一样,没有任何明显区别,所以问题不应该是创建Command对象这里,大家可以省略对象创建的时间了.2):Command更新时间
另外LZ的时间确实奇怪,在空表的情况下,我Insert 1000条数据只要6s,Insert 10000条只要1分钟,在表中有15万条记录的情况下,Insert 1000 条和10000条的时间和空表插入时间几乎还是一样的.3):Question
问题是不是出在数据库和表结构上?LZ不妨把你的数据库,表结构和更新语句发出来,让大家了解的更清楚一些,这样也许大家可以帮你找到问题所在.PS:我测试的机器是普通PC(xp+vs2003),数据库服务器双CPU+1G Memory+win2000+Sql Server2000,随便建了一个测试表
 create table InsertTest 
(filed1 nvarchar(30) null,field2 nvarchar(30) null,field3 nvarchar(100) null)

Answer 54

ADO.NET建议偶们最好全都在DATASET里去完成,最后空闲下来,在更新回数据库去吧.

Answer 55

command.CommandText = "insert into ..... insert into ";//xia写一百个insert into 语句。
偶像！如果是1万条记录，是不是要写10000条sql语句？？？？？？？？？？？恐怖。

Answer 56

? 
command.CommandText = "insert into ..... insert into ";//xia写一百个insert into 语句。
偶像！如果是10万条记录，是不是要写100000条sql语句？？？？？？？？？？？恐怖。

Answer 57

兄弟们不要再争了，不要太相信自己的主观判断，用AQTime剖析一下程序的运行情况，看看时间到底消耗在哪些代码段上，再针对这些代码进行优化。

Answer 58

这个问题两年前我们就遇到过。当时用ado.net1 吧。我记得当时测试的结果是：
1。从文本取数据再多也不慢（一次全部取入），应该说比想象中快得多；
2。就是把取出的数据放到DataTable中，这个耗内存，但速度不并慢。
3。当最后生成Insert的语句，往SQLSERVER数据库中执行，非常慢。

Answer 59

大家都使用MS的标准写法 
但要记住 MS的东西提倡的是方便 
效率向来就不怎么地
而且内存也特能吃 
所以听听别的意见还是有好处的

Answer 60

一点数据库角度的观点供参考
1、一次执行大批量sql语句的情况下，参数化的sql语句效率比每次一个sql语句高得多，有兴趣的各位可以参考一下数据库的资料，这个和上层程序无关的。（注，对于非参数化sql，即使'select 1'和'select 2'都会被数据库判定为完全不同的sql语句而重新解析 ）2、建议使用存储过程3、ODBC的优点在于使用简单和标准接口，而不在于执行效率...

Answer 61

思路上有问题，应该写sql脚本用sql2000的DTS或者sql2005的数据复制技术（如果希望定期执行可以制定sql执行计划），具体的网上很多相关资料的。

Answer 62

SQL Server: BULK INSERT
Oracle: 外部表我都用过，速度很快

Answer 63

command.CommandText = "insert into ..... insert into ";//xia?一百?insert into ?句。
偶像！如果是1万???，是不是要?10000?sql?句？？？？？？？？？？？恐怖。-----------------------------------
你誤解人家意思了!insert into語句是用循環生成，不是一條一條手動寫進去，這不可能!

Answer 64

用XML做参数，写个存储过程插入数据库，就建立一次链接，肯定快。
CREATE PROCEDURE pt_BooksInsertBorrowList
     @strXMLList text   --xml串
AS
      
declare @hdoc int
exec sp_xml_preparedocument @hdoc output,@strXMLListinsert into BooksBorrowList (BookBorrowID, BookID, BookBorrowCardID, BookBorrowUserCode, BookBorrowUserName, BookBorrowDate, BookBorrowPlanReturnDate,
  BookManageUserCode, BookManageUserName, BookBorrowIsKeepOn, BookBorrowFatherID, BookBorrowRe, BookReturnRe)
select  BookBorrowID, BookID, BookBorrowCardID, BookBorrowUserCode, BookBorrowUserName, BookBorrowDate, BookBorrowPlanReturnDate,
  BookManageUserCode, BookManageUserName, BookBorrowIsKeepOn, BookBorrowFatherID, BookBorrowRe, BookReturnRe
from openxml(@hdoc,'/root/record',2 ) 
with (BookBorrowID int,BookID varchar(50),BookBorrowCardID varchar(50),BookBorrowUserCode varchar(50),BookBorrowUserName varchar(50),BookBorrowDate datetime,
 BookBorrowPlanReturnDate datetime,BookManageUserCode varchar(50),BookManageUserName varchar(50),BookBorrowIsKeepOn int,BookBorrowFatherID int,BookBorrowRe varchar(500),BookReturnRe varchar(500))

Answer 65

SqlCommand command = null;            try
            {
                command = conn.CreateCommand();
                command.CommandText = @"Insert Into TBName(F1,F2,F3...)Values(@F1,@F2,@F3...)";
SqlParameter p1=command.Parameters.Add("@F1",DbType.NChar,10);
SqlParameter p2=command.Parameters.Add("@F2",DbType.NChar,10);
SqlParameter p3=command.Parameters.Add("@F3",DbType.NChar,10);
                command.CommandType = CommandType.Text;


While(eof()) //假设的循环
{
p1.Value=v1; //赋值
p2.Value=v2; //赋值
p3.Value=v3; //赋值
                 command.ExecuteNonQuery();
}
            }
            catch (SqlException e)
            {
                //...
            }//这样肯定快

Answer 66

ADO.NET 是很强的，在SQL SERVER中 OLEDB 的效率要比ODBC 高；
ADO.NET 比以前的ADO 效率要高，前提是你必需正确的使用它。楼主一定是组合了一个很大的SQL 串，如此大的串传递给SQL SERVER本身就需要很大的资源，和时间。
将SQL串适当的减小，并且使用参数，使SQL串保持不变。SQL SERVER就会很高重复效率执行，这样比执行一个大字符串效率高。

Answer 67

请教各位大虾：
1、
SqlCommand command = null;try
{
     command = conn.CreateCommand();
     command.CommandType = CommandType.Text;
     //用循环语句拼接100条。
     command.CommandText = "insert into ..... insert into   ";
     
     //如果拼接语句时有参数，再用循环语句给command添加参数     return command.ExecuteNonQuery();
}
catch (SqlException e)
{
    //...
}
======================
2、SqlCommand command = conn.CreateCommand();
command.CommandType = CommandType.Text;
try
{
     //用循环语句拼接100条。
     for(int i = 0; i < 100; i++)
     {
         command.CommandText = "insert into ..... ";
         //如果拼接语句时有参数，再用循环语句给command添加参数
         command.ExecuteNonQuery();
     }
}
catch (SqlException e)
{
    //...
}那种方法更快？

Answer 68

harmfulbug(飛翔的天堂鳥) ( ) 信誉：96 你的实际测试肯定不精确，重复创建对象是花时间的,虽然不多，但楼主是70W条记录，要重复70万次.
关于IConnection和IDataCommand对象的创建之前我做过测试的,重复创建对象和重复打开关闭连接都会明显影响性能.当时测试的好象是oledb的

Answer 69

2):Command更新时间
insert语句执行的时候，随着数据量增多，会越来越慢，除非你的表里面没有任何主键和索引.你可以重新测试一下.

Answer 70

3)表结构，这个也有可能，如果都是insert的话，可以考虑先删除索引，等操作执行完再重建索引，效率应该会高一些.