在C#中从Oracle数据库select 100条数据,是用存储过程快,还是C# sql语句快

孙大诚_SunRobin 2016-10-21 03:05:21
现在的需求很简单,从Oracle数据库中根据一定的参数检索数据。这里有2个选择,一个是直接在C#中写SQL语句,另一个是C#调用数据库上的存储过程。

个人根据第二种方式快一些,是这样的吗?有人能解释一下为什么吗?
...全文
769 16 打赏 收藏 转发到动态 举报
写回复
用AI写文章
16 条回复
切换为时间正序
请发表友善的回复…
发表回复
老衲是光头 2016-10-24
  • 打赏
  • 举报
回复
引用 15 楼 sundacheng1989 的回复:
[quote=引用 13 楼 sp1234 的回复:] 如果你写 select * from tabel where field_a > 1 跟 select * from tabel where field_a > 100 在SQL Server中,虽然常量改变了,后者也会自动使用前者的编译结果(常量可为变量)。只不过在系统启动之后,也许第一次出现那个 sql 查询时需要(瞬间)编译和分析一下,但并不是只有存储过程才嫩保存编译结果,普通的 sql 查询语句的编译结果也是缓存的数据库中的。
多谢多谢。 现在还有一个问题,就是比如说100万条数据放到数据库中,用C#的话,用sqlcommand,是把100万个insert语句拼成一个字符串,还是foreach一下,每个insert语句放到一个command中去执行,然后执100万次,这样是不是差别会很大?[/quote] 100万个insert语句?你百度一下SqlBulkCopy类,批处理添加的。
孙大诚_SunRobin 2016-10-23
  • 打赏
  • 举报
回复
引用 13 楼 sp1234 的回复:
如果你写 select * from tabel where field_a > 1 跟 select * from tabel where field_a > 100 在SQL Server中,虽然常量改变了,后者也会自动使用前者的编译结果(常量可为变量)。只不过在系统启动之后,也许第一次出现那个 sql 查询时需要(瞬间)编译和分析一下,但并不是只有存储过程才嫩保存编译结果,普通的 sql 查询语句的编译结果也是缓存的数据库中的。
多谢多谢。 现在还有一个问题,就是比如说100万条数据放到数据库中,用C#的话,用sqlcommand,是把100万个insert语句拼成一个字符串,还是foreach一下,每个insert语句放到一个command中去执行,然后执100万次,这样是不是差别会很大?
孙大诚_SunRobin 2016-10-23
  • 打赏
  • 举报
回复
引用 10 楼 caozhy 的回复:
100个数据没有什么区别。好比理论上北边更冷,但是在一个操场上,你站在哪里温度其实都差不多。
那个100个我举例子的时候考虑的有点不周到,其实真实情况是要从Excel读取100万条数据放到Oracle的数据库中。
  • 打赏
  • 举报
回复
如果你写 select * from tabel where field_a > 1 跟 select * from tabel where field_a > 100 在SQL Server中,虽然常量改变了,后者也会自动使用前者的编译结果(常量可为变量)。只不过在系统启动之后,也许第一次出现那个 sql 查询时需要(瞬间)编译和分析一下,但并不是只有存储过程才嫩保存编译结果,普通的 sql 查询语句的编译结果也是缓存的数据库中的。
  • 打赏
  • 举报
回复
至少对于 SQL Server 来讲,普通的 sql 语句也照样需要编译,而其编译步骤也会被缓存。换句话说,别说完全同样地 sql 语句了,就算不是条件查询sql语句,就算是 where 条件中的常量改变了,SQL Server 也一样是会重复使用之前的编译规划的,并不需要重新编译、重新分析优化。 要知道大型的商品化系统,都是千锤百炼地针对长期使用的测试用例进行了优化的,不像一些小的个人开发的数据库系统样考虑的测试用例仅仅是很简单的应用需求。对于”重用编译和规划策略“的问题,并不是仅仅对存储过程才会重用编译和规划。 这个问题其实就跟“用c#还是用c(不是c++/CLI)编程更快一样,我们可以说后者理论上似乎总是要”更快“的。那么为什么不用c、不用dos 下汇编去编程,而要用 .net 下的 c# 编程呢?
隔壁黎叔叔 2016-10-22
  • 打赏
  • 举报
回复
如果是很简单的SQL的话,我觉得SQL编译和存储过程第一次编译的时间估计不会相差太大。而查询的时间应该是一样的,不存在什么效率的问题,毕竟只是形式不一样而已。快慢产生的地方主要应该是在编译和交互的过程。 而第二次以后应该就是存储过程比较快了。 因为从存储过程的定义来看:存储过程(Stored Procedure)是在大型数据库系统中,一组为了完成特定功能的SQL 语句集,存储在数据库中,经过第一次编译后再次调用不需要再次编译。
threenewbee 2016-10-21
  • 打赏
  • 举报
回复
100个数据没有什么区别。好比理论上北边更冷,但是在一个操场上,你站在哪里温度其实都差不多。
水哥阿乐 2016-10-21
  • 打赏
  • 举报
回复
我敢说差别不大,你想查某个表时,就算用存储过程中不也是要写的select语句吗? 你要条件查询不管那种方式你得向数据库传递参数.至于那边快些只能说代码质量问题. 存储过程接受一个参数能办到的换个方法你这边sqlcommand就没必要向数据库传二个参数, 与其把注意力放在这个上面纠结不如放在代码优化和数据库优化上面
  • 打赏
  • 举报
回复
如果你有很多条语句,那么编写为一个存储过程来进行复杂的数据计算操作从理论上来说是比从客户端发送多条独立的查询语句要快。 但是具体你的程序是否使用存储过程快,你应该自己写一个测试来记录一下执行时间。一般来说,当你写的查询并不是“一大堆查询”,那么其实可能没有多大价值去写存储过程。要知道一个系统中维系几百个存储过程的修改(需要打开数据库工具去维护几百个过程,进行一些修改调试,然后再重新回到c#程序来启动),是很烦人的,不如直接了当地修改c#源程序更简单直接。
SoulRed 2016-10-21
  • 打赏
  • 举报
回复
查询语句非常复杂的时候存储过程可能会快点,但不是一定比直接写SQL快。具体实际效果建议你测试下,毕竟只有测试才是最能体现事实的
闭包客 2016-10-21
  • 打赏
  • 举报
回复
sql server 的话,存储过程可以保证重用执行计划。 大的差别就这一点。
孙大诚_SunRobin 2016-10-21
  • 打赏
  • 举报
回复
楼上说的都很对,确实是数据量大的时候应该用存储过程。 如果单个的插入的话,对于每一次插入操作,C#代码与远端的数据库服务器都会有一次通信,也就是C#发个message过去,返回一个执行结果回来。这叫一个round trip. 需要消耗network与CPU。如果数据量非常庞大,几十万条的时候,会比较明显。 如果使用ODP.NET BULK INSERT与存储过程相结合,这个会非常的高效率。 这是从官网查到的:http://www.oracle.com/technetwork/issue-archive/2009/09-sep/o59odpnet-085168.html
EnForGrass 2016-10-21
  • 打赏
  • 举报
回复
如果参数比较多,还是建议用存储过程
  • 打赏
  • 举报
回复
纠结这差值以ms为单位的有意思么……
圣殿骑士18 2016-10-21
  • 打赏
  • 举报
回复
如果sql是一条,就是一样快。如果sql语句是多条,就是存储过程快。
Poopaye 2016-10-21
  • 打赏
  • 举报
回复
存储过程难道是什么很特别的过程吗?

62,272

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术交流专区
javascript云原生 企业社区
社区管理员
  • ASP.NET
  • .Net开发者社区
  • R小R
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

.NET 社区是一个围绕开源 .NET 的开放、热情、创新、包容的技术社区。社区致力于为广大 .NET 爱好者提供一个良好的知识共享、协同互助的 .NET 技术交流环境。我们尊重不同意见,支持健康理性的辩论和互动,反对歧视和攻击。

希望和大家一起共同营造一个活跃、友好的社区氛围。

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