`
csd_ali
  • 浏览: 134018 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

数据库性能分析、优化入门

阅读更多

 

 最近参加了公司一位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;

  

 

解决方案: 

建索引: (POSTER_MEMBER_ID, POSTER_ROLE,STATUS, GMT_REMARK_MODIFIED DESC, ID DESC),从普通表中完成分页转为索引内完成分页,减少回表需要读取的页面。
 
 
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics