超长时间的SQL查询该如何处理

我心依旧 2017-10-05 09:41:41
我这里有一个需求。

就是在数据库中查询一个值,然后因为数据库非常庞大,查询的时间很长,我现在的做法是用 BackgroundWorker 组件放到线程中进行的,但是有一个问题就是无法取消,一旦我 cancelsync 界面就死掉了。我 设置 sqlconnection 为 close 也不行,同样界面死掉。

然后我今天研究的时候突然发现还有

sqlcomm.BeginExecuteReader();
sqlcomm.BeginExecuteNonQuery();

之类的语句,是不是可以直接用SQL类实现类似于BackgroundWorker 的效果啊?而且这样的话可以直接取消正在进行的查询。
我是怕正在查询如果直接关掉窗体的话,因为那个connection没有close,会不会占用资源啊。


不知道各位能不能看懂我写的,因为sql这一块其他的用法用的不多,都是老老实实的用着一套模板,还是想多了解一些其他的用法!谢谢
...全文
944 22 打赏 收藏 转发到动态 举报
写回复
用AI写文章
22 条回复
切换为时间正序
请发表友善的回复…
发表回复
zbdzjx 2017-10-11
  • 打赏
  • 举报
回复
看急不急着要结果了。急着要,就优化语句。 之前写的软件,计算考勤,要几分钟,就让他们开两个系统,一个点计算后,放一边不管它。用另一个系统再操作其他的。
leeya66 2017-10-11
  • 打赏
  • 举报
回复
以前在一个软件公司待过,SQL语句真的是乱写的,只要功能能实现,其他的不管的。 我给他们从1分钟的报表优化到两秒钟,还遭到不屑的眼神。认为是无用功。 其实那个优化很简单,就是联表查询,以表为维度做查询。之前的语句是用游标,一行一行的算。
小灰狼 2017-10-11
  • 打赏
  • 举报
回复
楼主应该打开思路,不要局限在C#这个编程语言方面 我的建议是,对海量的数据进行周期性地归档,放到一个或者若干个中间结果表里,以后查询时在这些归档表中查 直接在海量数据库里查,无论哪个数据库都快不起来。直接查虽然也有方案,比如把数据分布在很多个服务器上,象 Hadoop、HBase 之类的,但那样你要改你的系统架构,会更复杂。
打老虎zz 2017-10-10
  • 打赏
  • 举报
回复
放别的地方去做吧 到时候通知回来
xuzuning 2017-10-10
  • 打赏
  • 举报
回复
因为查询需要很长的时间,所以就没必要做成即查即得的样子 完成一次完整的查询,保存至过渡表(或什么缓存机制中),以后的查询直接从过渡表中读取上次的结果 每当原始表发生增、删、改后,进行查询以更新过渡表
by_封爱 版主 2017-10-10
  • 打赏
  • 举报
回复
引用 14 楼 starfd 的回复:
我看到6个小时,觉得这是什么样的需求,能这么牛瓣 你这种东西用于什么场景的?如果实时性不高,完全可以通过job预先跑出来
一个查询就6个小时 你还觉得实时性高? 我觉得没有这样的需求啊. 所以 我也觉得 调度 执行 插入数据库你想要的结果... 然后查询今天以前的数据...这样才是最合理的...
linzhaohuan 2017-10-10
  • 打赏
  • 举报
回复
可以考虑分开存储、分批查询,提示SQL性能
  • 打赏
  • 举报
回复
我看到6个小时,觉得这是什么样的需求,能这么牛瓣 你这种东西用于什么场景的?如果实时性不高,完全可以通过job预先跑出来
ilikeff8 2017-10-09
  • 打赏
  • 举报
回复
先优化sql语句,用sql server或orcale自带的性能分析工具 再优化索引,分区 最后再优化代码,代码优化带来的收益最小
正怒月神 2017-10-09
  • 打赏
  • 举报
回复
不考虑表分区吗?
by_封爱 版主 2017-10-09
  • 打赏
  • 举报
回复
一个查询语句 6个小时???
我心依旧 2017-10-09
  • 打赏
  • 举报
回复
单纯查询正常保持在毫秒级以内是不假。但是我这个是执行一个存储过程,这个过程的目的是查询某个值在数据库内的位置(属于哪个表哪个字段)。加上数据库好几个T,正常查询出结果都在6小时以上,所以我就要考虑用 BackgroundWorker 。 何况除了这种情况,肯定还是有其他的情况会保持很长时间的查询(即使很少),我就是想学习一下如何去处理这种情况,能安全的从 connection 的 open 到 close 流畅的走完,还不影响界面,不会卡死。 谢谢,麻烦大家继续指点一二!!!
wang_peng_yl 2017-10-09
  • 打赏
  • 举报
回复
从你的情况看,你得用多线程去解决界面死掉的问题 即然BackgroundWorker 不行,那就执行用Thread吧,最原始的 楼上有说在sql优化上解决,这确实不假,但这个我估计难度得相当大 推荐 http://www.sufeinet.com/thread-3556-1-1.html 参考一下
小灰狼 2017-10-09
  • 打赏
  • 举报
回复
这么长的操作放在界面上开始启动,确实是设计有问题了 考虑一下连接如果突然被中断,你的数据库服务器该怎么做? 如果启动了两个客户端进程,每个进程点一次,你的服务器不是要运行12个小时,三个进程就18个小时……你的数据库服务器估计不用干别的工作了 从用户体验上看,数据库是不会返回当前任务的工作进度的,所以你整个进度条也没多大的意义 所以,劝楼主换下思路
秋的红果实 2017-10-08
  • 打赏
  • 举报
回复
sqlcomm.BeginExecuteReader(); sqlcomm.BeginExecuteNonQuery(); 这两个是.NET4.5有的东西,并不是sql的东西。是.NET以异步方式操作数据库服务器的。 你用他两个,还不如直接用backgroundworker组件呢。 既然是大数据,就不要考虑多线程,用上会更慢,除非你的机器是多个独立CPU的 你应该从sql服务器上解决问题,例如建立索引,分表,分区等,最好是能找到数据的特征,根据特征去处理 也可以考虑增加机器内存,CPU等。如果是数据巨大,sql优化的效果也是相对有限的
全栈极简 2017-10-08
  • 打赏
  • 举报
回复
优化你的SQL查询语句才是根本。
exception92 2017-10-07
  • 打赏
  • 举报
回复
查询的时候做一个等待进度条,但是如果查询等待时间过长,可以考虑优化语句了。
圣殿骑士18 2017-10-07
  • 打赏
  • 举报
回复
引用 2楼我是你的主体 的回复:
[quote=引用 1 楼 以专业开发人员为伍的回复:]sql 查询通常要保持在几百毫秒、或者最多2、3秒。如果太长时间,这本身就是设计上的 bug。你不改变,那就没法。
肯定是有长时间的查询的。[/quote]看楼主是水平不高,还犟脾气。你是来请教的吗?
  • 打赏
  • 举报
回复
sql 查询通常要保持在几百毫秒、或者最多2、3秒。如果太长时间,这本身就是设计上的 bug。你不改变,那就没法。
吉普赛的歌 2017-10-06
  • 打赏
  • 举报
回复
1. sqlcomm.BeginExecuteReader(); sqlcomm.BeginExecuteNonQuery(); 之类的语句,是不是可以直接用SQL类实现类似于BackgroundWorker 的效果啊?而且这样的话可以直接取消正在进行的查询。 -- 可以的。 2. 我是怕正在查询如果直接关掉窗体的话,因为那个connection没有close,会不会占用资源啊。 -- 如果你直接关掉窗体, connection 肯定会关闭的了。 -- 而且在你的异步回调函数中, 还是得有关闭连接的方法, 如果执行完了自然就关闭了, 不用考虑这个问题。 3. 楼上其它人所说的, 你的设计的问题。 -- 确实如此, 时间太长的, 你可以考虑将其制作为报表, 凌晨执行并将其保存到为结果表, 白天仅是取其结果就好了。 -- 如果不能制作为报表, 你应该将相关的 SQL , 表结构, 索引等贴出来, 让大家帮你优化SQL。
加载更多回复(2)

110,500

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • Web++
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧