1、优化SQL语句，SQL语句对查询速度影响最大
2、对于经常查询的字段作索引。
② sql存储过程耗时太长
多长都有可能，40是很正常的。
1．尽量优化语句，尽量少用游标。
2．修改较为常用的表要注意，最好先在临时表中作好运算和其它处理，最后在修改这些表，以免较慢的存储过程长时间锁定表记录，影响数据正常使用。
3．将连接超时和命令超时适当扩大，以免超时错误。
③ sql语句和存储过程执行速度的问题
一千万条数据，数据是一样的，执行相同的insert语句
也就是 SQL 语句，只分析一次， 然后执行 一千万次。
理论上 存储过程的会快一点， 因为 存储过程 在 sql 调用的时候，只调用 1次， 然后服务器端 执行 一千万次 insert 操作。 然后返回一次结果给客户端。
sql 语句的话， 要在 sql 客户端 发起 一千万次调用， 服务端执行 一千万次 INSERT操作， 然后 返回 一千万次 执行结果给 客户端。
④ 存储过程比SQL语句慢的问题,痛苦中.....
1首先存储过程是预编译，按理说应该会比程序运行的语句效率高，如果时间反而长的话，可能是统计信息没有及时更新导致优化器给存储过程与单语句生成了不同的查询计划，而用片面的统计信息生成的查询计划会导致索引利用率低效，试试更新统计信息或者重建/重组索引
2一次提交查询6、7百次？这样的系统我还未见过，如果可以的话，现将需要的表数据缓存到服务器或者本地内存中，在内存中进行数据的操作，当然存储过程对复杂的查询会有一定的优化效果的
⑤ sql server存储过程执行速度慢如何优化
语句拿出来，帮你看一下。
存储过程，实际上和SQL语句区别不大，就是提前编译了。
有的时候还不如SQL语句，最起码语句连在一起算事务，存储过程需要自己起事务。
⑥ SQL 2005存储过程莫名慢
你在查询分析器里，先打开“执行计划”，然后执行存储过程，跟踪看慢在哪里吧
⑦ SQL Server中，存储过程执行速度比较慢，有优化的方案吗
主要有两种方法
1、优化SQL的逻辑，使得逻辑越简单越好。
2、使用到的表结构要建索引
⑧ oracle数据库存储过程执行慢时如何优化
1 首先看看，先分析慢的原因，一部分是因为循环次数多，一部分是因为查询数据量大慢。
2 可以从优化查询入手，比如某次查询的sql里面的数据，条件字段没有建索引，导致了全表扫描，
是不是 只需要几个字段，但是你写了 select * 等等，总之要优化数据的速度。
2 可以从循环逻辑看起，有些循环可能是不必要的，能不能通过条件查询来替代循环，总之要从逻辑上优化代码
⑨ mysql 存储过程执行太慢怎么优化
1.当我们请求mysql服务器的时候,MySQL前端会有一个监听,请求到了之后,服务器得到相关的SQL语句,执行之前(虚线部分为执行),还会做权限的判断
2.通过权限之后,SQL就到MySQL内部,他会在查询缓存中,看该SQL有没有执行过,如果有查询过,则把缓存结果返回,说明在MySQL内部,也有一个查询缓存.但是这个查询缓存,默认是不开启的,这个查询缓存,和我们的Hibernate，Mybatis的查询缓存是一样的,因为查询缓存要求SQL和参数都要一样,所以这个命中率是非常低的（没什么卵用的意思）。
3.如果我们没有开启查询缓存,或者缓存中没有找到对应的结果,那么就到了解析器,解析器主要对SQL语法进行解析
4.解析结束后就变成一颗解析树,这个解析树其实在Hibernate里面也是有的,大家回忆一下,在以前做过Hibernate项目的时候,是不是有个一个antlr.jar。这个就是专门做语法解析的工具.因为在Hibernate里面有HQL，它就是通过这个工具转换成SQL的,我们编程语言之所以有很多规范、语法,其实就是为了便于这个解析器解析,这个学过编译原理的应该知道.
5.得到解析树之后,不能马上执行,这还需要对这棵树进行预处理,也就是说,这棵树,我没有经过任何优化的树,预处理器会这这棵树进行一些预处理,比如常量放在什么地方,如果有计算的东西,把计算的结果算出来等等...
6.预处理完毕之后,此时得到一棵比较规范的树,这棵树就是要拿去马上做执行的树,比起之前的那棵树,这棵得到了一些优化
7.查询优化器，是MySQL里面最关键的东西,我们写任何一条SQL,比如SELECT * FROM USER WHERE USERNAME = toby AND PASSWORD = 1,它会怎么去执行?它是先执行username = toby还是password = 1?每一条SQL的执行顺序查询优化器就是根据MySQL对数据统计表的一些信息,比如索引,比如表一共有多少数据,MySQL都是有缓存起来的,在真正执行SQL之前,他会根据自己的这些数据,进行一个综合的判定,判断这一次在多种执行方式里面,到底选哪一种执行方式,可能运行的最快.这一步是MySQL性能中,最关键的核心点,也是我们的优化原则.我们平时所讲的优化SQL,其实说白了,就是想让查询优化器,按照我们的想法,帮我们选择最优的执行方案,因为我们比MySQL更懂我们的数据.MySQL看数据,仅仅只是自己收集到的信息,这些信息可能是不准确的,MySQL根据这些信息选了一个它自认为最优的方案,但是这个方案可能和我们想象的不一样.
8.这里的查询执行计划,也就是MySQL查询中的执行计划,比如要先执行username = toby还是password = 1
9.这个执行计划会传给查询执行引擎,执行引擎选择存储引擎来执行这一份传过来的计划,到磁盘中的文件中去查询,这个时候重点来了,影响这个查询性能最根本的原因是什么?就是硬盘的机械运动,也就是我们平时熟悉的IO,所以一条查询语句是快还是慢,就是根据这个时间的IO来确定的.那怎么执行IO又是什么来确定的?就是传过来的这一份执行计划.(优化就是制定一个我们认为最快的执行方案,最节省IO,和执行最快)
10.如果开了查询缓存,则返回结果给客户端,并且查询缓存也放一份。
⑩ SQL存储过程比SQL语句慢，甚至卡死
楼主，你好！这个排版屌爆了%>_<%
USE[HERP_BHYY]
GO
/******对象:StoredProcere[dbo].[sp_]脚本日期:12/03/201308:36:35******/
SETANSI_NULLSON
GO
SETQUOTED_IDENTIFIERON
GO
ALTERPROCEDURE[dbo].[sp_]
@ImpDateasDATETIMEASBEGIN
--SETNOCOUNTON;
DECLARE@ST_DATEASDATETIME
DECLARE@ED_DATEASDATETIME
DECLARE@TEMP_DATEDATETIME
IF@ImpDateisnotnull
begin
SET@ST_DATE=LEFT(@ImpDate,10)
SET@ED_DATE=dateadd(day,1,@ST_DATE)
end
deletehisdb2.dbo.his_charge_acc_o
wherecharge_date>=@ST_DATEandcharge_date<@ed_date
insert=""into=""hisdb2.dbo.his_charge_acc_o=""
select=""invoice_type=""from=""
where=""charge_date="">=@ST_DATEandcharge_date<@ED_DATE
end
这样不是挺好么？
上面的SQL语句貌似漏了什么东西，你自己看看