- 浏览: 98601 次
- 性别:
- 来自: 上海
文章分类
最新评论
-
j2eemylove:
是“恋舞OL”,给班同学做个广告
解码为中文 -
j2eemylove:
你当时有没有想到可能是不同字符间的转换问题了?!
解码为中文 -
everne:
唉,问题还没解决www.einverne.tk
重新设置ubuntu的用户密码
背景:维护反映客户现场的一个页面打开的速度非常慢,把该功能执行的sql语句输出到日志文件导回本地。
现象:
- 在本地执行非常快,查看执行计划,有五张表是全表扫描。
- 在客户现场查看执行,有七张表是全表扫描,逻辑读是9000多,执行时间为5秒左右,下面是客户现场的执行计划。
------------------------------------------------------------------------------ | Id | Operation | A-Rows | A-Time | Buffers | ----------------------------------------------------------------------------- | 1 | SORT GROUP BY | 1 |00:00:05.05 | 9154 | |* 2 | FILTER | 10060 |00:00:05.17 | 9154 | |* 3 | HASH JOIN | 60710 |00:00:05.11 | 9072 | |* 4 | FILTER | 60710 |00:00:05.15 | 5558 | |* 5 | HASH JOIN OUTER | 61672 |00:00:05.03 | 5558 | |* 6 | HASH JOIN | 61672 |00:00:06.92 | 3166 | | 7 | MERGE JOIN CARTESIAN | 4368 |00:00:00.03 | 18 | | 8 | MERGE JOIN CARTESIAN | 728 |00:00:00.01 | 16 | | 9 | TABLE ACCESS BY INDEX ROWID| 28 |00:00:00.01 | 3 | |* 10 | INDEX RANGE SCAN | 28 |00:00:00.01 | 2 | | 11 | BUFFER SORT | 728 |00:00:00.01 | 13 | | 12 | VIEW | 26 |00:00:00.01 | 13 | | 13 | UNION-ALL | 26 |00:00:00.01 | 13 | |* 14 | TABLE ACCESS FULL | 0 |00:00:00.01 | 3 | |* 15 | FILTER | 26 |00:00:00.01 | 10 | | 16 | TABLE ACCESS FULL | 26 |00:00:00.01 | 7 | |* 17 | TABLE ACCESS FULL | 0 |00:00:00.01 | 3 | | 18 | BUFFER SORT | 4368 |00:00:00.01 | 2 | |* 19 | TABLE ACCESS BY INDEX ROWID| 6 |00:00:00.01 | 2 | |* 20 | INDEX RANGE SCAN | 9 |00:00:00.01 | 1 | |* 21 | TABLE ACCESS FULL | 55658 |00:00:00.11 | 3148 | | 22 | TABLE ACCESS FULL | 183K|00:00:00.18 | 2392 | | 23 | TABLE ACCESS FULL | 144K|00:00:00.14 | 3514 | |* 24 | TABLE ACCESS FULL | 17 |00:00:00.01 | 82 | ------------------------------------------------------------------------------
解决办法:
- 通过加hits,建议数据库用索引来访问数据(注意:只是建议,数据库有权拒绝)。
- 执行时间由5秒降到了0.5秒,这不是重点,让人惊讶的是逻辑读由9000上升到了15000,为什么会这样?逻辑读增加了1.5倍,执行时间却降到了原来的1/10,这是以前没遇到过的现象。
下面是加了hits之后的执行计划
------------------------------------------------------------------------------ | Id | Operation | A-Rows | A-Time | Buffers | ------------------------------------------------------------------------------ | 1 | SORT GROUP BY | 1 |00:00:00.53 | 14946 | |* 2 | FILTER | 10060 |00:00:01.03 | 14946 | | 3 | MERGE JOIN CARTESIAN | 60710 |00:00:03.04 | 14864 | |* 4 | FILTER | 2335 |00:00:01.44 | 14851 | | 5 | NESTED LOOPS OUTER | 2372 |00:00:00.29 | 14851 | | 6 | NESTED LOOPS | 2372 |00:00:00.21 | 7899 | |* 7 | HASH JOIN | 2372 |00:00:00.16 | 3153 | | 8 | MERGE JOIN CARTESIAN | 168 |00:00:00.01 | 5 | | 9 | TABLE ACCESS BY INDEX ROWID | 28 |00:00:00.01 | 3 | |* 10 | INDEX RANGE SCAN | 28 |00:00:00.01 | 2 | | 11 | BUFFER SORT | 168 |00:00:00.01 | 2 | |* 12 | TABLE ACCESS BY INDEX ROWID| 6 |00:00:00.01 | 2 | |* 13 | INDEX RANGE SCAN | 9 |00:00:00.01 | 1 | |* 14 | TABLE ACCESS FULL | 55897 |00:00:00.11 | 3148 | | 15 | TABLE ACCESS BY INDEX ROWID | 2372 |00:00:00.04 | 4746 | |* 16 | INDEX UNIQUE SCAN | 2372 |00:00:00.02 | 2374 | | 17 | TABLE ACCESS BY INDEX ROWID | 2036 |00:00:00.06 | 6952 | |* 18 | INDEX RANGE SCAN | 2036 |00:00:00.02 | 4748 | | 19 | BUFFER SORT | 60710 |00:00:00.07 | 13 | | 20 | VIEW | 26 |00:00:00.01 | 13 | | 21 | UNION-ALL | 26 |00:00:00.01 | 13 | |* 22 | TABLE ACCESS FULL | 0 |00:00:00.01 | 3 | |* 23 | FILTER | 26 |00:00:00.01 | 10 | | 24 | TABLE ACCESS FULL | 26 |00:00:00.01 | 7 | |* 25 | TABLE ACCESS FULL | 0 |00:00:00.01 | 3 | |* 26 | TABLE ACCESS FULL | 17 |00:00:00.01 | 82 | ------------------------------------------------------------------------------
通过观察这俩个执行计划,发现未加hits的时候,HASH JOIN 后的行数是61672行,加了hits之后,HASH JOIN 后的行数是2372行,而且HASH JOIN 的时间也大大缩短,由此推断,
虽然没加hits之前,逻辑读少,但是产生的中间数据太多,消耗内存和cpu,而加了hits之后,虽然逻辑读多了1.5倍,但产生的中间数据却少了很多,既节省内存,又节省cpu。这也给我提供了一个新的优化sql思路,并不像一些博文说的,优化的终极目标就是降低逻辑读,除此之外,还要关注sql执行的中间过程。
发表评论
-
使用push_subq优化SQL
2013-08-19 15:40 2094需要优化的SQL SELECT * FROM (SE ... -
hints的push_pred应用
2013-04-15 14:34 944前俩年在项目中优化了一条SQL,当时从40多秒减少到了2秒, ... -
抽取sequence的创建语句
2012-12-06 19:44 974select 'create sequen ... -
强制删除用户
2012-11-02 13:22 941强制删除关联的session DECLARE ... -
druid配置
2012-11-01 16:01 13180web.xml配置,监控jsp和do请求,exclusions ... -
导入导出
2012-07-17 10:53 0SELECT * FROM All_Directo ... -
Oracle诊断事件列表
2012-06-07 16:49 1253来自http://www.eygle.com/internal ... -
记一次页面无响应调式过程
2011-10-12 09:15 1709现象 在发文节点,点击确定,页面没有响应. 调 ... -
ORACLE备份&恢复案例
2011-08-27 11:26 487ORACLE备份&恢复案 ... -
创建视图需要注意的问题
2011-08-23 15:35 1564创建视图报错 SQL> create or re ... -
获取执行计划的4种方式
2011-08-20 10:26 1275获取执行计划的4种方式 1:从计划表中获取,计划表名默 ... -
DBMS_STATS包使用
2011-08-19 09:53 2372有时候,想查看一下表中数据的增删改次数,可以使用视图USER_ ... -
获取运行时执行计划和统计信息
2011-08-03 13:26 1475在sql语句中加入提示/*+ gat ... -
hints
2011-08-01 13:58 8681:索引 SELECT /*+ index(e(ENT ... -
SQL Plus使用入门
2011-07-31 12:40 1038转载自: http://blog.csdn.net/wj ... -
sqlplus
2011-07-27 10:06 10781:输出结果到文件 spool c:\zhj.txt; ... -
c3p0配置参数
2011-07-23 13:31 1048c3p0配置参数: acquireIncreme ... -
记一次数据库优化
2011-07-20 16:46 804背景:电子政务系统显示公文数据列表打开的时候速度非常慢 ... -
sql_trace
2011-07-19 15:51 12181:设置sql_trace SQL>alter ... -
重建用户下的所有索引
2011-06-10 16:59 1272重建用户下的所有索引 DECLARE STR V ...
相关推荐
一次交换收到的 消息到处理线程 写比读要频繁 分成读写锁 一次交换到写线 程批次写入 不频繁操作, 注意锁定时间 游戏服务器的线程处理 服务器监控及性能优化全文共27页,当前为第17页。 MMO服务器常用的优化手段 ...
这样读取效率就比较高,因为一次读取就可能包含了两个表中的数据,因此提高了查询效率。要解决“磁盘数据组织不合理,导致磁盘的访问次数过多”这个问题,我们可以将经常读写的数据放置在不同的磁盘上,也就是将经常...
执行效果:表'Trainee'扫描计数1,逻辑读取189次,物理读取0次,预读0次 修改后: SELECT * FROM TRAINEE WHERE TraineeNo 执行效果:表'Trainee'扫描计数1,逻辑读取3次,物理读取0次,预读0次 使用Top语句...
11.3.4 一次统计信息收集不准确引发的NL性能瓶颈 329 11.4 本章习题、总结与延伸 332 第12章 动手,经典等价改写让SQL飞 333 12.1 设法减少访问路径 333 12.1.1 Case When改造 334 12.1.2 Rownum分页改写 337 ...
, 然而,SQL虽然实现简单可乐,却极易引发性能问题,那时广大SQL使用人员可要“愁”就一个字,心碎无数次了。, 缘何有性能问题?原因也一字概括:“量”。当系统数据量、并发访问量上去后,不良SQL就会拖跨整个系统...
, 然而,SQL虽然实现简单可乐,却极易引发性能问题,那时广大SQL使用人员可要“愁”就一个字,心碎无数次了。, 缘何有性能问题?原因也一字概括:“量”。当系统数据量、并发访问量上去后,不良SQL就会拖跨整个系统...
然而,SQL虽然实现简单可乐,却极易引发性能问题,那时广大SQL使用人员可要“愁”就一个字,心碎无数次了。 缘何有性能问题?原因也一字概括:“量”。当系统数据量、并发访问量上去后,不良SQL就会拖跨整个系统,...
对磁盘I/O进行优化的主要目的和方法是尽量减少磁盘的读写次数,加大数据的一次处理量,提高数据存储的空间分配及管理。 1 基于SQL语句的优化器 优化器的类型。数据库在被访问的时候,都是执行SQL语句,在执行之前...
11.3.4 一次统计信息收集不准确引发的NL性能瓶颈 329 11.4 本章习题、总结与延伸 332 第12章 动手,经典等价改写让SQL飞 333 12.1 设法减少访问路径 333 12.1.1 Case When改造 334 12.1.2 Rownum分页改写 337 ...
考虑到sql语句每一次执行都要建立连接,查询,获取数据耗时过多。就想到将sql一起提交上去运行,能够节省很多时间。原本1.6-2.5秒耗时的sql语句经过修改后时间降到0.3-0.6秒,感觉性能提升挺好的。 当然还有一种想法...
Parse to execute ratio:在生产环境,最理想状态是一条sql语句一次解析多数运行。 公式:1 - (parse count/execute count) 执行: select 1-(a.value/b.value) from v$sysstat a,v$sysstat b where a.name='...
福建省电力公司调度中心曾抽查华能福州电厂机组的一次调频性能,得出的结论是:一二期4台机组的一次调频性能均达不到省网的要求,普遍存在响应时间不及时、响应幅度太小、响应持续时间不足等缺陷。福建省调要求福州...
能够一次连接就获取到结果的,就不用两次连接,这样可以大大减少对数据库无用的重复请求在应用中,我们可以在应用中增加 缓存 层来达到减轻数据库负担的目的。缓存层有很多种,也有很多实现方式,只要能达到降低...
以下是整理出来的些许代码习惯: 1)字符串的比较 用 string.Empty 代替 ” ” 2)在遍历过程中,先定义好计数变量, 再遍历, 这样会减少每次遍历就分配一次内存空间: 代码如下: int i; for( i=0; i<100;i++) { /...
众所周知的Android系统每隔16ms重新绘制一次activity,也就是说你的app必须在16ms内完成屏幕刷新的所有逻辑操作,这样才能达到60帧/s。而用户一般所看到的卡顿是由于Android的渲染性能造成的。本篇博客将介绍Android...
当我们扩展到更低的几何尺寸时,实现良好的逻辑和物理综合比以往任何时候都更重要。 虽然合成工具在过去的几年里有了很大的发展,但是要想在高性能设计上获得最佳质量的结果(QOR),设计师必须超越传统的工具开关。...
在讲解时,先通过理论对先关的优化知识进行了铺垫,然后使用实际的案例详细的演示了每一次的优化操作。 并且在课程的最后,还讲解了如何使用MySQL实现主从同步功能。 本课程大致包含了以下几方面的内容: 1.MySQL...
在第一次重构中,请格外注意应用程序的逻辑部分(尤其是 bodyForce 函数)能够并且应该基本保持不变:要侧重于尽可能轻松地加速应用程序。 代码库包含 main 函数内的“for 循环”,用于将 bodyForce 函数计算的物体...