一条很复杂的sql语句与n条简单的sql语句比,哪个效率高?

newlovedew 2015-04-17 10:02:59
都是在连接open以后提交语句,一条复杂语句就是操作全由数据库完成,多条简单点的语句是一部分工作由数据库完成,一部分由C#程序完成
...全文
1542 29 打赏 收藏 转发到动态 举报
写回复
用AI写文章
29 条回复
切换为时间正序
请发表友善的回复…
发表回复
_iorilan 2017-01-14
  • 打赏
  • 举报
回复 1
取决于你的具体操作业务逻辑以及数据库环境。 简而言之,减少链接数据库操作;查询时尽量少锁表;查询少join表;表非聚簇索引的创建也很重要。
dream_maker2333 2017-01-13
  • 打赏
  • 举报
回复
看情况而定,多次和数据库交互也会耗时的
JTZP007 2015-04-22
  • 打赏
  • 举报
回复
来个实例~~~
leeya66 2015-04-21
  • 打赏
  • 举报
回复
是的,最新我在做一个查询是通过时间字段聚会后做表连接,效率很慢, 后来 我拆成多条后在C#里面做了几个foreach,整体速度快很多, 运算量也分流了,原本全部都是数据库层面的活,拆了一部分到用户的客户端PC上,
Dogfish 2015-04-21
  • 打赏
  • 举报
回复
这个不能一概而论。要看你的连接次数和你复合语句的效率。
  • 打赏
  • 举报
回复
我们对于那些不具有执行力、而貌似高大上的理论,那些其实很难以让我们用代码方式为它编织自动化的“安全网”的所谓各种“规范”,要持开放的态度。 我们只是坚持那些可以运行起来的规范,而且高强度地每天运行上万次。只要做到这一点,剩下那些议论性的纠结的理论,自然而然就有了它要服务的目标了。
  • 打赏
  • 举报
回复
我经常强调使用“亲自写测试程序”作为评判标准,而不是用抽象的“是否有洁癖”作为标准。 对于这个问题,你能否比较方便地写一个测试程序来数量化地测试“和复杂的sql、很简单的sql”这种东西呢?如果能,你会每天运行它100遍以上吗?如果不能,这就是告诉我们自己“仅仅停留在议论上了”。我不对于那些不具有执行力、而貌似高大上的理论,要谨慎使用。
  • 打赏
  • 举报
回复
“一条很复杂的sql语句”如果被充分简单化,而你的应用并未见太大的性能下降,例如仅仅从1秒钟变为1.3秒(慢了30%),那么往往是完全可能去进行这种简单化重构的。 这个要看具体的工程方面的分析,不要太技术化了!对不同人一定有不同的答案,其关键点就在于能够数量化地说出一些实际的的用户体验和组织工程体验的指标,而不是仅仅比较抽象地说“很复杂、n条简单的sql”这类。
渃水 2015-04-20
  • 打赏
  • 举报
回复
引用 10 楼 kingjt 的回复:
原则是不要频繁的操作数据库,如果你的多条语句需要不停的OPEN和CLOSE数据库连接,建议还是整合成一条语句。 如果效率影响不大,建议分多条语句,好维护。
我的想法和这位相同
software_artisan 2015-04-19
  • 打赏
  • 举报
回复
引用 14 楼 wanghui0380 的回复:
这个我们不做分析,因为对于效率问题。我们和博客园的区别是 他们喜欢假定有罪,而我们喜欢假定无罪 我们需要实测证明他有罪,才会优化。 而实测的情况 两种情况都可能发生性能问题。所以这问题在没有具体语境的情况下是没有答案的。而假定有罪滴程序员其实犯的错更多,因为他们会更早滴在毫无根据的情况下做毫无根据的优化,写出自以为很高明的低效语句出来
+1
StuClass 2015-04-18
  • 打赏
  • 举报
回复
一条好点,多条语句意味着多个查询结果以及多次遍历。实现同样功能的多条和一条语句,当然是一条更好。
卖水果的net 2015-04-18
  • 打赏
  • 举报
回复
完成相同的任务,一条语句快。 多条语句,肯定慢,尤其是两条语句之间的,还有c# 的动作。
zujinsheng 2015-04-18
  • 打赏
  • 举报
回复 1
尽量减少与数据库的交互次数.. 建议一条
wanghui0380 2015-04-18
  • 打赏
  • 举报
回复
这个我们不做分析,因为对于效率问题。我们和博客园的区别是 他们喜欢假定有罪,而我们喜欢假定无罪 我们需要实测证明他有罪,才会优化。 而实测的情况 两种情况都可能发生性能问题。所以这问题在没有具体语境的情况下是没有答案的。而假定有罪滴程序员其实犯的错更多,因为他们会更早滴在毫无根据的情况下做毫无根据的优化,写出自以为很高明的低效语句出来
leeya66 2015-04-18
  • 打赏
  • 举报
回复
如果没有水平写出优秀的SQL语句,导致查询时间超过1秒的,可以考虑在本机处理一些数据,
  • 打赏
  • 举报
回复
这个不好说,没有具体场景,有可能一条效率高,有可能多条效率高
姓小名白丶 2015-04-17
  • 打赏
  • 举报
回复
这个问题没有特定的条件,没什么意义。即使是交给C#代码处理查询,归根结底还是要调用SQL语句在数据库中进行查询并且返回,效率谈不上什么什么优化。如果要是用存储过程,那么效率肯定就大不一样了。 (纯属小白的个人理解,仅供参考)
xuzuning 2015-04-17
  • 打赏
  • 举报
回复
一次做和分几次做,从做的角度上看是一样的 但分次做就有与程序交互的问题,会减慢执行的速度 SQL 在收到指令后,有一个分析优化过程。显然复杂的指令要比简单的指令多耗费点时间 所以,你应该用存储过程将复杂的指令化为多条简单的指令 由于存储过程只在建立时有分析优化过程,因此执行起来效果要好的多
xdashewan 2015-04-17
  • 打赏
  • 举报
回复
引用 3 楼 newlovedew 的回复:
如果是操作很复杂 不会影响性能么
这真不能一概而论,这和你操作的具体复杂程度,操作记录的具体数目,数据库服务器性能及负荷各种因素都会影响执行效率
newlovedew 2015-04-17
  • 打赏
  • 举报
回复
自己顶下,,,,
加载更多回复(7)
更优更快 人工智能自动SQL优化----------http://www.sina.com.cn 2001/12/12 17:48 中国电脑教育报文/SQL爱好者  所谓SQL,就是指Structured Query Language(结构化查询语言),它是目前使用最广泛的数据库语言,用来和数据库打交道,从数据库中得到用户需要的数据。但是要想熟练使用SQL语句,也不是一件简单的事,有些语句使用起来也比较麻烦。如果我们对SQL语句进行优化,那么用户使用起来 就会方便许多。  简单来说,SQL语句的优化就是将性能低下的SQL语句转换成达到同样目的的性能优异的SQL语句。人工智能自动SQL优化就是使用人工智能技术,自动对SQL语句进行重写,找到性能最好的等效SQL语句。  人工智能自动SQL 优化  随着人工智能技术的发展和在数据库优化领域应用的深入,在20世纪90年代末终于出现了突破性的进展——人工智能自动SQL优化。目前在商用数据库领域LECCO TechnologyLimited(灵高公司)拥有该技术并提供使用该技术的自动优化产品——LECCO SQL Expert,其支持Oracle、Sybase、MS SQLServer和IBMDB2数据库平台。该产品针对数据库应用的开发和维护阶段提供了几个特别的模块:SQL语法优化器、PL/SQL集成化开发调试环境(IDE)、扫描器、数据库监视器等。图1 人工智能自动SQL优化示意图  其核心模块之一“SQL语法优化器”的工作原理大致如下(如图1):  SQL语句输入→“人工智能反馈式搜索引擎”对输入的SQL语句结合检测到的数据库结构和索引进行重写,产生N等效的SQL语句输出→产生的N等效SQL语句再送入“人工智能反馈式搜索引擎”进行重写,直至无法产生新的输出或搜索限额满→对 输出的SQL语句进行过滤,选出具有不同执行计划的SQL语句(即不同的执行效率)→对得到的SQL语句进行批量测试,找出性能最好的SQL语句。图2 优化前的SQL语句  自动优化实例  假设我们从源代码中抽取出这SQL语句(如图2):  SELECTCOUNT(*)FROMEMPLOY-EE WHEREEXISTS(SELECT'X'FROM DEPARTMENTswheresEMP_DEPT=DPT_IDAND DPT_NAME LIKE'AC%')AND EMP_IDIN(SELECT SAL_EMP_IDFROM EMP_SAL_HISTB WHERESAL_SALARY>70000)   按“优化”按钮后,经过十几秒,SQL Expert就完成了优化的过程,从优化细节中可以看到,它在十几秒的时间内重写产生了2267等价的SQL语句,其中136SQL语句有不同的执行计划(如图3)。图3 优化结果  接下来我们可以对自动重写产生的136具有不同执行计划的SQL语句进行批运行测试,以选出性能最佳的等效SQL语句。按下“批运行”按钮,在“终止件”页选择“最佳运行时间SQL语句”(如图4),按“确定”。图4 测试件  经过几分钟的测试运行后,我们可以发现SQL124的运行时间和反应时间最短。运行速度约有22.75倍的提升(源SQL语句运行时间为2.73秒,SQL124运行时间为0.12秒,如图5)。图5 测试结果  我们把SQL124放入源代码中,结束SQL语句的优化工作。从上例可以看到,LECCO SQL Expert的自动重写技术使原来需要几小时才能完成的SQL语句的优化工作,缩减到几分钟之内就可以完成。数据库管理员和开发人员可以从繁重的SQL语句优化工作中解脱出来。  边做边学式训练  LECCO SQL Expert不仅能够找到最佳的SQL语句,而且提供的“边做边学式训练”还能够教会开发人员和数据库管理员如何写出性能最好的SQL语句。LECCO SQL Expert的“SQL比较器”可以标明源SQL和待选SQL之间的不同之处。LECCO SQL Expert详尽的上下文敏感帮助系统可以指出执行计划的深层含义。图6 源语句与SQL124的比较  以上面优化的结果为例,为了查看源SQL语句和SQL124在写法上的不同,我们可以按下“比较器”按钮,对SQL124和源SQL语句进行比较。如果选择“双向比较”复选框,“SQL比较器”可以将两互相间的不同之处以蓝色表示。当然,你也可以从 源语句和重写后的SQL语句中任选两进行比较(如图6)。  从比较的结果可以看到,重写得到的SQL124把第一个Exists改写成了In;在字段DPT_ID上进行了合并空字符串的操作以诱导数据库先执行子查询中的(SELECTDPT_ID||'FROMDEPART-MENTWH

110,538

社区成员

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

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

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