SQL优化是重点

信息系统访问量又不大，瓶颈一般不会出现在应用层，极有可能在数据库这一层，不用急着看程序。先找出逻辑读取次数最多的SQL，硬盘读取次数最多的SQL，找到SQL，对于SQL进行优化。看看有没有发生全表扫描的地方。
一般发生全表扫描，极有可能是没有建立合理的索引，或者索引由于左边引用函数或其它原因造成索引失效。
对于运行一年多的系统，最好要自己写一个自动重建索引的程序，定时重建索引。
或者使用TOAD工具帮你重建索引。

另外在看一下数据库的CPU占用率，如果占用率在经常在80%－100%，那一定要是SQL或存储过程及trigger中写的不好。

不需要从应用层找SQL，方向性错误，太累，也看不出效果。
而应当使用pl/SQL, toad等工具，分析出最bad的SQL语句，一看到这些语句后，再修改应用层的查询就是了。又快又方便。



-- 逻辑读多的SQL
select * from (select buffer_gets, sql_text
from v$sqlarea
where buffer_gets > 500000
order by buffer_gets desc) where rownum<=30;

-- 执行次数多的SQL   
  select sql_text,executions from
  (select sql_text,executions from v$sqlarea order by executions desc)
   where rownum<81;

-- 读硬盘多的SQL 
  select sql_text,disk_reads from
  (select sql_text,disk_reads from v$sqlarea order by disk_reads desc)
   where rownum<21;    

-- 排序多的SQL   
  select sql_text,sorts from
   (select sql_text,sorts from v$sqlarea order by sorts desc)
    where rownum<21;           
 
--分析的次数太多，执行的次数太少，要用绑变量的方法来写sql
set pagesize 600;
set linesize 120;
select substr(sql_text,1,80) "sql", count(*), sum(executions) "totexecs"
   from v$sqlarea
   where executions < 5
   group by substr(sql_text,1,80)
   having count(*) > 30
   order by 2;

评论

18 楼 OneEyeWolf 2006-06-30  

同意楼上的，做事不能钻角尖，设计时当然不能教科书般的追求面对象的完美，面向关系的范式化，但这只是设计。但调优就是在运行期的调优，决不是设计期间，所能解决的。
    一味的强调设计，只是那此不懂设计的人，没有实际调优经验的人说的话。没有在实际中调优的人，相信也做不出性能良好的的架构。

   举一个例子，原来在实际项目中，数据库CPU居高不下，通过分析工具分析出来一个很BAD的SQL，先是在程序中找，没有发现。后来是在一个存储过程中的一段代码中发现的。这些Bad SQL并不是设计所能决定的了的。设计只能做到基础的未来能够面对高并发的可扩展的架构。

17 楼 zhoulf 2006-06-30  

santafeng 写道

zhoulf 写道

SQL绝对是重点！！

如果是ormapping那如何优化sql？
我感觉还是设计的时候应该考虑数据量和程序的压力，sql优化只能后期做。表和程序做不好或者用错了框架，sql怎么优化最后能提高的性能很有限。

ormapping 也是实体对数据库表的映射而已，最后反映到数据库中的还是Sql,SQL的结构和你的表结构设计有很大的关系。你难道说SQL不是重点？如果你只是简单的一两张表的数据查询，那么我相信70%的人写出来的SQL都是一样的。

一般来说，程序写的不好也绝对没有一个BAD SQL 来的厉害。至于框架，如果不用这样那样的框架呢？你能说它性能就不行了？？
至于你说的“我感觉还是设计的时候应该考虑数据量和程序的压力”，那是前提。而且也不会没有事情就跑去SQL优化，一般都是很有针对行的！

16 楼 forfail 2006-06-18  

Oracle把个软件做的配置，优化那么复杂，真是扯淡

这种公司是最应该翘翘的，甭管微软怎样，人家用户体验是做的真不错。

15 楼 戏说乾隆 2006-06-16  

如果每个人都能这么把自己认为最好的心得写出来，中国的技术进步就快了，呵呵呵

14 楼 戏说乾隆 2006-06-16  

好文章，感谢 呵呵

13 楼 xiaoych 2006-06-16  

santafeng 写道

zhoulf 写道

SQL绝对是重点！！

如果是ormapping那如何优化sql？
我感觉还是设计的时候应该考虑数据量和程序的压力，sql优化只能后期做。表和程序做不好或者用错了框架，sql怎么优化最后能提高的性能很有限。

  有意思……如果我的系统没有用数据库呢？

12 楼 santafeng 2006-06-15  

zhoulf 写道

SQL绝对是重点！！

如果是ormapping那如何优化sql？
我感觉还是设计的时候应该考虑数据量和程序的压力，sql优化只能后期做。表和程序做不好或者用错了框架，sql怎么优化最后能提高的性能很有限。

11 楼 zhoulf 2006-06-13  

SQL绝对是重点！！

10 楼 ray_linn 2006-06-07  

xiaozhou 写道

一个系统出现性能瓶颈，往往是设计阶段的问题，sql调优不能根本解决问题。

这话说得太次了。。

9 楼 yyanghhong 2006-05-23  

另外可以用DBMS_SQLTUNE对SQL进行分析， 他会自动给出改进意见， 比如数据表需要用dbms_stats.gather_schema_stats来统计一下， 或需要加index,  很方便的

8 楼 yyanghhong 2006-05-23  

9i里的statspack和10 g里的AWR, 都可以给出一段时间里所有SQL的统计， 比如

SQL ordered by Elapsed Time
SQL ordered by CPU Time
SQL ordered by Gets
SQL ordered by Reads
SQL ordered by Executions
SQL ordered by Parse Calls

7 楼 赵小刀 2006-05-22  

Allen 写道

xiaozhou 写道

一个系统出现性能瓶颈，往往是设计阶段的问题，sql调优不能根本解决问题。

这话说得有些太过片面了啊……

80%的性能问题，是由20%的糟糕的sql所导致的。sql调优可以解决一大部分的性能问题。

6 楼 hgq0011 2006-05-17  

OneEyeWolf 写道

信息系统访问量又不大，瓶颈一般不会出现在应用层，极有可能在数据库这一层，不用急着看程序。先找出逻辑读取次数最多的SQL，硬盘读取次数最多的SQL，找到SQL，对于SQL进行优化。看看有没有发生全表扫描的地方。

谢谢
有对sql server,mysql,,,优化的SQL吗?

5 楼 Allen 2006-05-16  

xiaozhou 写道

一个系统出现性能瓶颈，往往是设计阶段的问题，sql调优不能根本解决问题。

这话说得有些太过片面了啊……

4 楼 xiaozhou 2006-05-16  

一个系统出现性能瓶颈，往往是设计阶段的问题，sql调优不能根本解决问题。

3 楼 ithero 2006-03-29  

长见识了,感谢楼主的贡献的SQL

2 楼 歆渊 2006-03-29  

呵呵, Oracle就是好啊, 有这么多方便的工具机制, 这是一个成熟软件的核心价值所在!

1 楼 huaronghu 2006-03-29  

OneEyeWolf 写道

信息系统访问量又不大，瓶颈一般不会出现在应用层，极有可能在数据库这一层，不用急着看程序。先找出逻辑读取次数最多的SQL，硬盘读取次数最多的SQL，找到SQL，对于SQL进行优化。看看有没有发生全表扫描的地方。

谢谢你贡献的SQL!