原文：http://www.javaeye.com/topic/811222
最近参加了公司一位DBA关于数据库性能的分析，觉得讲得挺不错的，因此做下总结，也算是一种积累。
这个博文整体结构分为三个部分：
第一部分，阐述数据库的数据存储结构；
第二部分，SQL性能分析（核心部分）；
第三部分，SQL调优实例。
1 数据库的数据存储结构
在开始性能优化前，首先需要对优化的对象进行了解，这样我们才能抓住问题的本质。
页面（BLOCK）
数据库中最小的分配，读取单元，一般来说，设置为8K大小。
表
数据库中的表，是由一些列的页面（block）组成
页面物理上可以不连续，但是逻辑上是连续的
索引
索引也是由页面（block）组成
通常采用B+树的组织形式
2 SQL性能分析（核心部分）
重中之重：一条sql是否ok？如何优化？走索引是否可以提高性能？全在于下面一句话：
此SQL需要访问多少页面（BLOCK）！！！
为什么是这样的呢？原因是读页面是大量的IO操作，需要在内存中定位，或是外存中定位并加载，开销很大。而其他的SQL比较操作，>,=,like…，都是CPU计算，相对开销较小。
下面分别对几类常见SQL访问需要读取的页面（BLOCK）进行分析：
表全扫描
表中所有的页面（BLOCK）
索引全扫描
索引中所有的页面。优势：索引项相对于表项较小，页面更少
索引范围扫描
索引层数+范围中的BLOCK
索引唯一扫描
索引层数。优势：最小的页面访问量
索引扫描+回表扫描
索引BLOCK+表BLOCK
丛上面的分析可知，索引唯一扫描是最快的，也就是我们平常从某张表中根据唯一的ID查询一个唯一记录的SQL；表全扫描是最慢的，也就是需要遍历表中所有的记录。
3 SQL调优实例
这里先说一下，不是每个SQL需要优化的，如果SQL性能满足需求，是不需要做优化的。
出了性能问题的的SQL：
- SELECT *
- FROM (select rid
- FROM (select r.rid, rownum rnum
- FROM (select rowid rid
- FROM CREDIT_REMARK t
- WHERE t.POSTER_MEMBER_ID = :1 and t.POSTER_ROLE = #memberRole#
- ORDER BY t.GMT_REMARK_MODIFIED DESC, t.ID DESC) r
- WHERE rownum <= #endRow :INTEGER#)
- WHERE rnum > #startRow :INTEGER#) t1,
- CREDIT_REMARK t2
- WHERE t1.rid = t2.rowid ORDER BY t2.GMT_REMARK_MODIFIED DESC, t2.ID DESC;
解决方案：
