深入剖析-关于分页语句的性能优化

分页语句是数据库开发和应用场景比较常见的需求,即按照特定的where条件进行过滤,然后在按照一个或者多个条件进行排序(如果不进行排序无法确执行时候无法返回相同的结果),最后取其中的前十行或者几十行。

一般分页语句消耗资源的地方有两点:

1、返回where条件过滤的结果集;

2、是对这个结果集进行排序,如果表过大同时对返回的结果集排序势必导致性能严重下降,针对分页语句性能低下的原因。

优化分页语句的核心思想:

1、创建效率高的索引返回尽量少的结果集排序;

2、因为索引是有序的,直接让数据库读取有序索引数据避免进行排序。

下面就针对不同的分页语句场景做如何优化。

正确的分页语句框架

分页场景一:针对分页语句的优化

首先我们要确定正确的分页语句框架,如果不按照正确的分页语句框架编写,会严重影响oracle选择正确的执行计划,正确的分页语句框架如下:

select * from
( select * from
( select a.*,rownum rn from
( 写好的sql语句 ) a
) where rownum<=m
) where rn>=n;

针对正确的分页语句和错误的分页语句会产生不同的执行计划,举例如下:

SQL> create table t as select * from dba_objects;
Table created.
SQL> select count(*) from t;
COUNT(*)
----------
497070

我们要写好的sql语句,如下:

select * from t where object_id<1000 返回前10行

针对这个sql语句,如果T表比较大的话,全表扫描就会非常消耗资源,我们针对object_id列创建索引即可。object_id列选择性非常高,对1000列进行排序性能也很高。创建如下索引:

create index t_idx_id on t(object_id);

然后再套用正确的分页语句框架,去执行高级执行计划:

Set linesize 200 pagesize 200
alter session set statistics_level=all;
select * from
( select * from
( select a.*,rownum rn from
( select * from t where object_id<1000 ) a
) where rownum<=10
) where rn>=0;
select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));

采用正确的分页语句框架执行计划走的是T_IDX_ID索引,分页语句显示10行,执行计划中A-ROWS是10行。我们再看看采用其他错误分页语句显示的高级执行计划:

从错误的执行语句框架中我们可以看到,只要不是正确分页语句框架,oracle都会扫描<1000行最后显示10行数据。

针对上述语句的优化方案我们需要注意2点:

1、采用正确的分页语句框架;

2、针对where条件创建选择性高、效率高、索引返回少的结果集。

order by 分页

分页场景二: select * from t order by object_id 基于某列排序再分页

因为索引是排序的,我们可以利用索引的排序功能。在排序的分页语句中如果我们让分页语句直接按照升序或者降序扫描索引,这样的话就避免了全表扫描再排序的这种消耗资源操作。但是我们不确定object_id列是否有非空约束,由于索引是不存空值的,为了能够保证可能为空的object_id列也存在索引中,我们要在索引中添加一个组合列的常量索引,创建索引语句如下:

create index T_IDX_ID0 on t (object_id,0);

执行计划如下:

注:如果有些优化器没走索引可以在sql语句中增加一个索引的hint。

where等值条件过滤order by分页

分页场景三: select * from t where owner=’SYS’ order by object_id 有where条件过滤,然后基于某列排序再分页

这类分页语句我们要如何创建索引? 因为oracle对这类语句执行过程是先过滤where条件再排序,所以我们创建一个组合索引,给予OWNER,OBJECT_ID列组合(不能颠倒)

create index T_IDX_owner_ID on t (owner,object_id);

以此类推,where owner='SYS' order by object_id, object_name 这类基于 owner,object_id,object_name列建组合索引。

where不等值条件过滤order by分页

分页场景四: select * from t where where object_id<100000 order by owner 语句中的where条件是非等值,然后order by 其他列

这种情况我们就不能按照【分页场景三】进行优化,这类语句我们要分两种情况:

第一种where条件过滤后的结果集比较少,我们就采用【分页场景一】进行优化直接创建效率高的索引。

第二种where条件过滤后结果集比较多,这种我们就要 order by列在前,不等值列在后创建组合索引。

create index T_IDX_owner_ID on t (owner,object_id);

执行计划如下:

注:以上两种情况没有明显的分界线,特别是针对反对结果集比较适中的情况,还要综合比较两种创建索引方法谁的执行效率更高而采用哪种方案。

多表关联的分页语句

分页场景五:多表关联的分页如何优化select * from a,b where a.id=b.id order by a.id;

这类分页语句的优化思想是:既然是多表关联的分页语句,一定是走嵌套循环,不能走hash连接,最后要order by 某个表,一定是 order by的那个表做驱动表,同时驱动表的 order by列必须有索引。

无法优化的分页语句

无法优化的分页场景:但是如果是这种需求select * from a,b where a.id=b.id order by a.xx,b.xxx 这种需要对两个表排序情况下就无解了(为什么会搞基于两个表排序的需求,淘宝京东的商品排序大多数是只按照一种属性排序,如按照销量排序,按照价格排序,综合排序),这种情况需要干掉一个 order by 的列。

如果分页语句中有distinct, group by等需要把表数据全部扫描之后再去排序分页的,这种就无法用专门分页语句进行优化了。

总结

以上几种分页场景基本包含了目前主要的分页语句的需求和实现,不同的分页语句有一种或者几种优化方案。首先根据【优化场景一】的内容,先选择标准的分页语句框架,然后判断whete条件过滤后的结果集条数是多还是少。如果返回结果集少,则创建效率高的索引;如果返回结果集非常多,则考虑【分页场景二,三,四】,为分页语句创建一个排序过滤好的索引直接返回结果。对于【无法优化的分页场景】,就要考虑其他手段了,比如说调整分页需求,增加where过滤条件,对大表进行分区和瘦身等其他优化方案。

原文发布时间为:2017-12-20

本文作者:任小闯

本文来自合作伙伴“数据和云”,了解相关信息可以关注“数据和云”微信公众号

时间: 2024-11-11 19:26:28

深入剖析-关于分页语句的性能优化的相关文章

mysql limit的分页用法与性能优化

mysql教程 limit 的性能问题 有个几千万条记录的表 on mysql 5.0.x,现在要读出其中几十万万条左右的记录 常用方法,依次循环: select * from mytable where index_col = xxx limit offset, limit; 经验:如果没有blob/text字段,单行记录比较小,可以把 limit 设大点,会加快速度 问题:头几万条读取很快,但是速度呈线性下降,同时 mysql server cpu 99% 速度不可接受. 调用 explai

MySQL单表百万数据记录分页性能优化技巧_Mysql

测试环境: 先让我们熟悉下基本的sql语句,来查看下我们将要测试表的基本信息 use infomation_schema SELECT * FROM TABLES WHERE TABLE_SCHEMA = 'dbname' AND TABLE_NAME = 'product' 查询结果: 从上图中我们可以看到表的基本信息: 表行数:866633 平均每行的数据长度:5133字节 单表大小:4448700632字节 关于行和表大小的单位都是字节,我们经过计算可以知道 平均行长度:大约5k 单表总大

复杂SQL性能优化的剖析(二)(r11笔记第37天)

    昨天的一篇文章复杂SQL性能优化的剖析(一)(r11笔记第36天) 分析了一个SQL语句导致的性能问题,问题也算暂时告一段落,因为这个语句的执行频率是10分钟左右,所以优化后(大概是2秒左右,需要下周再次确认)的提升很大.    对于优化是一个持续的改进,我们碰到的问题,最终的原因可能五花八门,但是正如柯南所说,真相只有一个.我把这个问题和前几天处理的一个问题结合起来,前几天处理了一个紧急问题,也是有一个SQL语句的执行计划发生改变,这个语句的业务比较关键,触发频率是每分钟一次,如果一旦

数据库性能优化分析案例---解决SQL语句过度消耗CPU问题

解决|数据|数据库|问题|性能|优化|语句 问题描述:10月25日上午滨州网通的工程师报告OSS应用系统运行缓慢,具体操作是通过OSS系统查询话单,很长时间才能返回结果,严重影响了客户的正常使用. 问题处理:1.登陆数据库主机,用sar命令看到idle的值持续为0,CPU的资源已经耗尽: bz_db1# sar 2 4 SunOS kest 5.8 Generic_108528-19 sun4u    10/26/04 10:56:46    %usr    %sys    %wio   %id

oracle sql语句性能优化

oracle|性能|优化|语句 1.选用适合的ORACLE优化器ORACLE的优化器共有3种 A.RULE (基于规则) b.COST (基于成本) c.CHOOSE (选择性) 设置缺省的优化器,可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明,如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS . 你当然也在SQL句级或是会话(session)级对其进行覆盖. 为了使用基于成本的优化器(CBO, Cost-Based Optimizer) ,

ORACLE性能优化之SQL语句优化

文章来源:http://blog.csdn.net/jdzms23/article/details/23850783 版权声明:本文为博主原创文章,未经博主允许不得转载. 目录(?)[-] SQL语句执行过程 1 SQL语句的执行步骤 2 典型SELECT语句完整的执行顺序 3 SQL语句执行过程 优化器及执行计划 1 SQL优化方法论 合理应用Hints 1Hints 索引及应用实例 1什么是索引 2索引分类 3什么时候使用索引 4改写SQL使用索引 5索引应用 其他优化技术及应用 1其他优化

秋色园QBlog技术原理解析:性能优化篇:打印页面SQL,全局的SQL语句优化(十三)

文章回顾: 1: 秋色园QBlog技术原理解析:开篇:整体认识(一) --介绍整体文件夹和文件的作用 2: 秋色园QBlog技术原理解析:认识整站处理流程(二) --介绍秋色园业务处理流程 3: 秋色园QBlog技术原理解析:UrlRewrite之无后缀URL原理(三) --介绍如何实现无后缀URL 4: 秋色园QBlog技术原理解析:UrlRewrite之URL重定向体系(四) --介绍URL如何定位到处理程序 5: 秋色园QBlog技术原理解析:Module之页面基类设计(五) --介绍创建

SQL语句性能优化(续)_MsSql

上篇介绍了一下自己在项目中遇到的一种使用sql语句的优化方式(性能优化--SQL语句),但是说的不够完整.在对比的过程中,没有将max函数考虑在内,经人提醒之后赶紧做了一个测试,测试过程中又学到了不少的东西. 上次用的是select count(*) 和select * 的执行效率问题,因为我的需求是获取数据的一个总数来自动给出新的id,然后网友给出可以使用max的方式给出新id.其实这也是一种不错的思路(当时我们也用过该函数,只不过因为系统数据本身问题,不适合用该函数),然后我就对max函数的

.Net+SQL Server企业应用性能优化笔记3——SQL查询语句

在上一篇文章中我们使用了几种方法来确定瓶颈,找到瓶颈,下面再回顾一下: LoadRunner压力测试+Windows计数器,这种方法主要是找出大概的性能问题是在哪台服务器,主要是哪个资源紧张. ANTS Profiler+SQL Server Profiler,这两个工具的完美搭配可以准确的定位性能是出在哪个函数,哪个SQL语句上. 如果性能问题是出在程序上,那么就要根据业务对程序中的函数进行调整,可能是函数中的写法有问题,算法有问题,这种调整如果不能解决问题的话,那么就要从架构上进行考虑,我们