好烦,这个保存的速度问题真不知要如何弄了?在线等
有个界面中 可以让用户扫入条码,数据量在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查询. 就可以知道哪些存在,哪些不存在了.