当前位置:首页 » 服务存储 » 写存储过程会降低性能吗
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

写存储过程会降低性能吗

发布时间: 2022-06-03 19:43:34

❶ 项目中所有sql语句全用存储过程写,例如select * from A最简单的也用存储过程,是否能优化性能

看情况的,存储过程会缓存数据,如果查询条件经常变动的话,简单的SQL语句还是不要使用存储过程比较好,会增加服务器压力的,反之,对于经常使用的一些语句,如果基本上都没怎么变动的话,用存储过程应该是会好点的

❷ 用存储过程能提高性能吗,为什么

可以,在数据库层的效率比在程序中高

❸ 用存储过程会使程序的性能更好么

存储过程使用不麻烦,你把存储过程写在数据库里,使用强类型DataSet作数据访问层。自己写一个业务逻辑层,然后再应用层调用。这样直接访问数据的代码都是VS给你生成的,保证安全性,正确性和代码规范性。
你觉得存储过程使用麻烦主要是因为你不会使用。
上面几位都说了,存储过程可以提高性能,减少服务器间的数据交换,防止Sql注入攻击,等等,既然有这些优势,微软怎么可能让它使用起来很麻烦呢?

❹ SQL SERVER 一个数据库中使用大量的存储过程,会影响性能吗

一、在SQL Server中存储过程不会影响性能。
1、只会大大的减轻服务器的压力,而不会增加,只有不合理的存储过程才会造成服务器性能下降的恶果。一个大型的数据库,一般存储过程也不会超过几千个,对当前的数据库及它依附的硬件来说,这点儿负载是大象身上的老鼠,负载基本可以怱略不计。
2、但是,存储过程是批量的SQL语句的合成,如果设计上混乱,引发死循环、死锁、大范围查询、临时表没有及时清理释放等问题的情况下,是会严重影响服务器性能的,但这根子不在存储过程上,而在于存储过程的设计上。错误的SQL代码指挥服务器,无论它的形式是存储过程,还是客户端及时发向数据库的请求,都会使服务器出现问题。

二、相关扩展
1、在当前,针对数据库的编程设计,没有存储过程是不可想象的,这就象某个公司的大型货品仓库中没有仓库保管员一样,所有的货品进出都得进货员或销售员去临时取放,会严重降低工作效率。
2、存储过程在数据库中无论是否编译好,其效率都要比客户端临时向数据库发送指令调数据来得要高,因为至少减少了发向服务器的指令的量。况且很多的中间值、临时值如果不通过存储过程来实现的话,就只能先全取到客户端,这样会大大增加网络负担与服务器的负钽。
3、正如微软所说,存储过程来实现,可以使得很多中间量不必传入到客户上,客户端只能得到需要的结果,所以同时可以提高安全。

❺ 存储过程的优缺点

存储过程的优缺点:
存储过程优点:
1.由于应用程序随着时间推移会不断更改,增删功能,T-SQL过程代码会变得更复杂,StoredProcere为封装此代码提供了一个替换位置。
2.执行计划(存储过程在首次运行时将被编译,这将产生一个执行计划--
实际上是
Microsoft
SQL
Server为在存储过程中获取由
T-SQL
指定的结果而必须采取的步骤的记录。)缓存改善性能。
但sql
server新版本,执行计划已针对所有
T-SQL 批处理进行了缓存,而不管它们是否在存储过程中,所以没比较优势了。
3.存储过程可以用于降低网络流量,存储过程代码直接存储于数据库中,所以不会产生大量T-sql语句的代码流量。
4.使用存储过程使您能够增强对执行计划的重复使用,由此可以通过使用远程过程调用
(RPC)
处理服务器上的存储过程而提高性能。RPC
封装参数和调用服务器端过程的方式使引擎能够轻松地找到匹配的执行计划,并只需插入更新的参数值。
5.可维护性高,更新存储过程通常比更改、测试以及重新部署程序集需要较少的时间和精力。
6.代码精简一致,一个存储过程可以用于应用程序代码的不同位置。
7.更好的版本控制,通过使用
Microsoft
Visual
SourceSafe
或某个其他源代码控制工具,您可以轻松地恢复到或引用旧版本的存储过程。
8.增强安全性:
a、通过向用户授予对存储过程(而不是基于表)的访问权限,它们可以提供对特定数据的访问;
b、提高代码安全,防止
SQL注入(但未彻底解决,例如,将数据操作语言--DML,附加到输入参数);
c、SqlParameter
类指定存储过程参数的数据类型,作为深层次防御性策略的一部分,可以验证用户提供的值类型(但也不是万无一失,还是应该传递至数据库前得到附加验证)。
存储过程缺点:
1.如果更改范围大到需要对输入存储过程的参数进行更改,或者要更改由其返回的数据,则您仍需要更新程序集中的代码以添加参数、更新
GetValue()
调用,等等,这时候估计比较繁琐了。
2.可移植性差
由于存储过程将应用程序绑定到
SQL
Server,因此使用存储过程封装业务逻辑将限制应用程序的可移植性。如果应用程序的可移植性在您的环境中非常重要,则将业务逻辑封装在不特定于
RDBMS
的中间层中可能是一个更佳的选择。
3.
大量采用存储过程进行业务逻辑的开发致命的缺点是很多存储过程不支持面向对象的设计,无法采用面向对象的方式将业务逻辑进行封装,从而无法形成通用的可支持复用的业务逻辑框架。
4.代码可读性差,相当难维护.

❻ mysql存储过程能优惠性能吗

这个性能问题很多都是相对的,譬如如果你不用存储过程,那应用服务器和数据库服务器的交互就会增多,这样也导致性能降低。一般而言,存储过程的使用降低应用的负载,更多的要考虑使用的合理性。譬如触发器过多也会影响你操作表的速度,因而你应该根据系统自身情况去分析设计