Parallel.For并发计算的问题

[liweibing2000]

程序代码如下：
Parallel.For(0,dt.ows.Count,i=>
{
SqlHelper.ExecuteNonQuery("delete Checked where SourceId=dt.Rows[i]["Id");
}
这样的一个删除功能。
config配置连接字符串加了：Connect Timeout=60;
运行大概几分钟就会报连接等待超时的错误。请问这个错误原因应该出在哪块。谢谢。

[以专业开发人员为伍]

如果你使用传统关系数据库，这不可能简单地并发多线程执行。 关系数据库要锁住 Checked 表的查询功能（好在你是直接指定了条件 SourceId=....，如果更复杂一点的条件将更容易死锁）。而且每一条语句单独作为一个数据库事务、启动了一个复杂的事务处理过程。 正确的做法，是将每（例如）200条“delete Checked where SourceId =...... ; ”语句合并到一个显式的 DbTransaction 中去执行，每一批处理才需要数据库端启动一个事务。然后使用单线程循环执行就可以了。

[liweibing2000]

引用 1 楼 sp1234 的回复:

如果你使用传统关系数据库，这不可能简单地并发多线程执行。 关系数据库要锁住 Checked 表的查询功能（好在你是直接指定了条件 SourceId=....，如果更复杂一点的条件将更容易死锁）。而且每一条语句单独作为一个数据库事务、启动了一个复杂的事务处理过程。 正确的做法，是将每（例如）200条“delete Checked where SourceId =...... ; ”语句合并到一个显式的 DbTransaction 中去执行，每一批处理才需要数据库端启动一个事务。然后使用单线程循环执行就可以了。

好的，学习了。谢谢指点。

[以专业开发人员为伍]

如果要并发多线程，显成数以尽量减到最少为宜。实际上单线程是最好的。 假设你的 where 条件写的不是这样简单直接，而是涉及到其它记录扫描，那么你根本不应该用2个线程，因为那样的事务之间是“互锁”的，用两个线程就没有任何意义了。 技术不会互锁，对关系数据库的事务也不能在不必要时过多并发处理。关系数据库的事务，在以前传统认识上（那些整天写个小OA的程序员的认识上）好像挺高大上地，实际上它是互联网时代的软件性能瓶颈。比如说应用服务器与数据库服务器不在同一个集群，那么网络延迟就会造成事务结束的时间很慢。而一个事务结束很慢，就会卡死数据库上其它一大堆事务。迅速造成恶性循环，数据库服务器根本撑不住。 所以就算是网络通讯速度问题都会显露出数据库事务的“容易拥塞”的弊端来。你在编程时不要滥用并发多线程来访问数据库，仅在必要时才用。 顺序操作往往比并发多线程操作更快。