Oracle性能优化一

性能优化（性能定位）

客户对产品的依赖性越强，对产品性能差的忍耐性越低。

 

性能优化原则

• 性能优化是一种面向客户的主观的感觉，不是所有的数据库都需要（能够）优化
• 数据库的性能，大多数都不是从数据库层面能够解决的
• 在不了解业务之前，不可能找到正确的优化思路
• 优化要有一个度，并不是“没有最优，只有更优”

导致性能问题的可能原因

• 表没有正确的创建索引——错误的执行计划
• 表没有及时的分析——错误的执行计划
• 热块——数据块的争用（反向索引解决？）
• 锁的阻塞——业务设计的缺陷
• SQL解析消耗大量CPU——变量绑定
• 低效的SQL——SQL自身的问题
• 数据库整体负载过程——架构设计的问题

性能问题的定位

原则：尽可能从小范围分析问题

SQL层

工具  执行计划 10053，10046

会话层（最有用的最靠谱，用的最多的）

V$SESSION，V$SESSTAT，V$SESSION_WAIT，V$SQL，V$LOCK，SQL_TRACE

系统层

AWR(STATSPACK),OS tools(top,iostat)

AWR数据报告（还是需要结合业务，此项并不重要，不要随便分析AWR），结合操作系统的工具

不要迷恋优化器

不要迷恋优化器，优化器永远无法知道你的业务需求

• 优化器永远无法按照你的业务需求来重写你的SQL语句
• 优化器只能在数学（集合）逻辑上做SQL得重写

高效的SQL来自于对业务的理解和对SQL执行过程的理解。

不要迷恋高级工具，关注底层原理，基础，和业务

SQL的难不在于写出功能性SQL，而在于在业务的基础上，写出运行高效的SQL

对结果集，SQL执行过程理解，才能写出高效的SQL

为什么高效的SQL这么难

1、SQL语言本质上是集合的运算

2、语言的效率，是SQL语言最难的地方

很多种访问的方式：

tablescan（全表扫描）

index range scan（索引范围扫描）

index fast scan（索引快速扫描）

nested loop join（嵌套循环表关联）

merge join（先各自排序，再作关联）

hash join（将各自哈希，再比对关联）

3、优化器机制开发者无法掌控