当前位置:首页 » 服务存储 » 存储过程比较慢
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

存储过程比较慢

发布时间: 2023-06-26 14:18:07

sql Server中,存储过程执行速度比较慢,有优化的方案吗

主要有两种方法
1、优化SQL的逻辑,使得逻辑越简单越好。
2、使用到的表结构要建索引

❷ oracle数据库存储过程执行慢时如何优化

在oracle中
不关是执行sql还是存储过程,当你第一次执行的时候需要对相关语句进行相关权限、对象等分析,这个过程会产生执行计划,叫做硬解析,如果分析通过,之后将语句转化成ascii等效数字码,再通过hash算法得到散列值,然后检查库缓存中是否存在同样hash值的语句。
如果存在,就是软解析.然后就执行语句得出结果.所以第一次执行的时候要是硬解析,速度较慢,而第二次已经以后多次执行的时候是软解析,速度较快.大概就这样
如果要详细说
这东西几个钟头都说不完的.

❸ JDBC执行存储过程异常慢

1.connection不知道你是采用什么方式获取的,如果不是从连接池里取,你每connection.close()一次,下次get的时候会重新建立实际物理链接,这样会相当耗时。所以你检查一下是在获取connection时耗的时间多,还是在execute的时间多。代码:
long startTime = System.currentTimeMillis();
conn = getConnection(); // execute();
long endTime = System.currentTimeMillis();
System.out.println("获取链接的时间:" + (endTime - startTime));
执行的类似;

2.从你的存储过程的逻辑来说,要条件查询,更新某个字段的值,和入库,这三个步骤应该有输入参数的,那么你的这个参数是怎么传入的?
个人觉得你的这个存储过程可以优化成SQL来执行,效率应该会更好:
首先,你把输入参数放入一个临时表;
比如结构是:
_id _field
查询的条件 更新的字段

// 更新_table中存在的记录的_field字段,并且只更新_table与_tmp键值相等的记录
UPDATE _table t SET _field=(SELECT MAX(_field) FROM _tmp WHERE _id=t._id) WHERE EXISTS (SELECT 'X' FROM _tmp WHERE _id=t._id);

// 选择_table与_tmp键值不相等的记录(即_table中不存在的记录)插入_table
INSERT INTO _table (_id,_field) (SELECT _id,_field FROM _tmp t WHERE NOT EXISTS (SELECT 'X' FROM _table WHERE _id=t._id));

这样的话,每次都是两个批量操作,而且不需要输入参数,直接调用就可以,唯一需要多做的工作就是做临时表。

❹ 单独执行很快,为什么在存储过程里面执行很慢

慢的原因是你在对List的循环中使用了List的get函数.
典型的"Shlemiel喷涂算法",所以越跑越慢啊.
List里是一个链表,get方法会从头一个个地数,越到后面,数的时间就越长.所以会慢..
你应该修改方式,用下面的方法进行循环:
for(Iterator it = list.iterator(); it.hasNext() ;){
Map map = (Map)it.next();
// ...
}

❺ 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.如果开了查询缓存,则返回结果给客户端,并且查询缓存也放一份。