日期:2014-05-19  浏览次数:20666 次

好烦,这个保存的速度问题真不知要如何弄了?在线等

  有个界面中   可以让用户扫入条码,数据量在2000条以上,
  当保存时我的做法是:

  用到sql   中的这个sp_xml_removedocument过程,在客户端行成xml,   一次把条码数   据作为参数传到存储过程中,在数据库端形成一个临时表,

    这个临时表中的每一条数据又要以某些条件查找在   一个表中是否存在,不存在就保存.     我是用游标做的..   然后,这个界面我用了多线程

      问题是,在速度上客户超不满意,我也不知道还能怎样优化了,各位有经验的能否指定一二,有更好的作法没?
 
   



------解决方案--------------------
不懂 帮顶
------解决方案--------------------
我想问题可能就是在游标上, 建议不要用游标.

把一些处理逻辑放在前台上处理吧.
------解决方案--------------------
select count(*) from tbl where no=01
------解决方案--------------------
mark
------解决方案--------------------
如果只是插入条码不如将
所有条码放在一个参数中 传给STORE PROCEDURE

然后在STORED PRODUCTE中 PARSE


如果你有索引的话
2000条应该非常块的

------解决方案--------------------
说一个方案,不对莫怪。

你的程序逻辑处理基本是靠数据库来完成的,尤其是用了游标。

我觉得你应该在程序初始化的时候,把数据库中已经有的字段的条码都拿出来。装载在内存中,以类似哈西表的形式。

以后每存一条的时候,先在哈西表里对比,这个速度应该是很快的,如果没有,就存入,有的话,就在数据库和哈西表里各增加一条记录。

这样,能减少数据库的负担,而且,可以读一条,存一条,不用一次全部存入(不太了解扫条吗是否可以读一个,存一个)。



------解决方案--------------------
你说说 要是实在不行,开4个线程 一个线程存500能块点不?
开10个 一个存200啊?
^^^^^
你说的某些条件 能定义成主键不呢?
------解决方案--------------------
要找出那里慢了

是查询 还是插入
还是sp_xml_removedocument慢了


------解决方案--------------------
对,首先搞清楚慢在哪里。
------解决方案--------------------
你用游标就是为了循环吧, 把这个循环放前台来. 速度会快很多的.

"这个临时表中的每一条数据又要以某些条件查找在 一个表中是否存在,不存在就保存. 我是用游标做的.. 然后,这个界面我用了多线程 "

我怀疑你是在用游标遍历这2000条数据, 再判断是否存在.
如果是这样的话, 建议你把这个临时表跟数据库中的那个表做一个left join查询. 就可以知道哪些存在,哪些不存在了.