首页 后端开发 php教程 (Oralce)Web翻页优化实例_PHP

(Oralce)Web翻页优化实例_PHP

Jun 01, 2016 pm 12:40 PM
and select 优化 实例

Web翻页优化实例

作者:Wanghai





环境:

Linux version 2.4.20-8custom (root@web2) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #3 SMP Thu Jun 5 22:03:36 CST 2003

Mem: 2113466368

Swap: 4194881536

CPU:两个超线程的Intel(R) Xeon(TM) CPU 2.40GHz



优化前语句在mysql里面查询15秒左右出来,转移到oracle后进行在不调整索引和语句的情况下执行时间大概是4-5秒,调整后执行时间小于0.5秒。



翻页语句:

SELECT * FROM (SELECT T1.*, rownum as linenum FROM (

SELECT /* index(a ind_old)*/

a.category FROM auction_auctions a WHERE a.category =' 170101 ' AND a.closed='0' AND ends > sysdate AND (a.approve_status>=0) ORDER BY a.ends) T1 WHERE rownum < 18681) WHERE linenum >= 18641



被查询的表:auction_auctions(产品表)

表结构:

SQL> desc auction_auctions;

Name Null? Type

----------------------------------------- -------- ----------------------------

ID NOT NULL VARCHAR2(32)

USERNAME VARCHAR2(32)

TITLE CLOB

GMT_MODIFIED NOT NULL DATE

STARTS NOT NULL DATE

DESCRIPTION CLOB

PICT_URL CLOB

CATEGORY NOT NULL VARCHAR2(11)

MINIMUM_BID NUMBER

RESERVE_PRICE NUMBER

BUY_NOW NUMBER

AUCTION_TYPE CHAR(1)

DURATION VARCHAR2(7)

INCREMENTNUM NOT NULL NUMBER

CITY VARCHAR2(30)

PROV VARCHAR2(20)

LOCATION VARCHAR2(40)

LOCATION_ZIP VARCHAR2(6)

SHIPPING CHAR(1)

PAYMENT CLOB

INTERNATIONAL CHAR(1)

ENDS NOT NULL DATE

CURRENT_BID NUMBER

CLOSED CHAR(2)

PHOTO_UPLOADED CHAR(1)

QUANTITY NUMBER(11)

STORY CLOB

HAVE_INVOICE NOT NULL NUMBER(1)

HAVE_GUARANTEE NOT NULL NUMBER(1)

STUFF_STATUS NOT NULL NUMBER(1)

APPROVE_STATUS NOT NULL NUMBER(1)

OLD_STARTS NOT NULL DATE

ZOO VARCHAR2(10)

PROMOTED_STATUS NOT NULL NUMBER(1)

REPOST_TYPE CHAR(1)

REPOST_TIMES NOT NULL NUMBER(4)

SECURE_TRADE_AGREE NOT NULL NUMBER(1)

SECURE_TRADE_TRANSACTION_FEE VARCHAR2(16)

SECURE_TRADE_ORDINARY_POST_FEE NUMBER

SECURE_TRADE_FAST_POST_FEE NUMBER



表记录数及大小

SQL> select count(*) from auction_auctions;



COUNT(*)

----------

537351



SQL> select segment_name,bytes,blocks from user_segments where segment_name ='AUCTION_AUCTIONS';



SEGMENT_NAME BYTES BLOCKS

AUCTION_AUCTIONS 1059061760 129280



表上原有的索引

create index ind_old on auction_auctions(closed,approve_status,category,ends) tablespace tbsindex compress 2;



SQL> select segment_name,bytes,blocks from user_segments where segment_name = 'IND_OLD';



SEGMENT_NAME BYTES BLOCKS

IND_OLD 20971520 2560

表和索引都已经分析过,我们来看一下sql执行的费用

SQL> set autotrace trace;

SQL> SELECT * FROM (SELECT T1.*, rownum as linenum FROM (SELECT a.* FROM auction_auctions a WHERE a.category like '18%' AND a.closed='0' AND ends > sysdate AND (a.approve_status>=0) ORDER BY a.ends) T1 WHERE rownum <18681) WHERE linenum >= 18641;



40 rows selected.



Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=19152 Card=18347 Byt

es=190698718)



1 0 VIEW (Cost=19152 Card=18347 Bytes=190698718)

2 1 COUNT (STOPKEY)

3 2 VIEW (Cost=19152 Card=18347 Bytes=190460207)

4 3 TABLE ACCESS (BY INDEX ROWID) OF 'AUCTION_AUCTIONS'

(Cost=19152 Card=18347 Bytes=20860539)



5 4 INDEX (RANGE SCAN) OF 'IND_OLD' (NON-UNIQUE) (Cost

=810 Card=186003)



Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

19437 consistent gets

18262 physical reads

0 redo size

114300 bytes sent via SQL*Net to client

56356 bytes received via SQL*Net from client

435 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

40 rows processed



我们可以看到这条sql语句通过索引范围扫描找到最里面的结果集,然后通过两个view操作最后得出数据。其中18502 consistent gets,17901 physical reads



我们来看一下这个索引建的到底合不合理,先看下各个查寻列的distinct值

select count(distinct ends) from auction_auctions;



COUNT(DISTINCTENDS)

-------------------

338965



SQL> select count(distinct category) from auction_auctions;



COUNT(DISTINCTCATEGORY)

-----------------------

1148



SQL> select count(distinct closed) from auction_auctions;



COUNT(DISTINCTCLOSED)

---------------------

2

SQL> select count(distinct approve_status) from auction_auctions;



COUNT(DISTINCTAPPROVE_STATUS)

-----------------------------

5



页索引里列平均存储长度

SQL> select avg(vsize(ends)) from auction_auctions;



AVG(VSIZE(ENDS))

----------------

7



SQL> select avg(vsize(closed)) from auction_auctions;



AVG(VSIZE(CLOSED))

------------------

2



SQL> select avg(vsize(category)) from auction_auctions;



AVG(VSIZE(CATEGORY))

--------------------

5.52313106



SQL> select avg(vsize(approve_status)) from auction_auctions;



AVG(VSIZE(APPROVE_STATUS))

--------------------------

1.67639401



我们来估算一下各种组合索引的大小,可以看到closed,approve_status,category都是相对较低集势的列(重复值较多),下面我们来大概计算下各种页索引需要的空间



column distinct num column len

ends 338965 7

category 1148 5.5

closed 2 2

approve_status 5 1.7



index1: (ends,closed,category,approve_status) compress 2

ends:distinct number---338965

closed: distinct number---2

index size=338965*2*(9 2) 537351*(1.7 5.5 6)=14603998



index2: (closed,category,ends,approve_status)

closed: distinct number---2

category: distinct number---1148

index size=2*1148*(2 5.5) 537351*(7 1.7 6)=7916279



index3: (closed,approve_status,category,ends)

closed: distinct number---2

approve_status: distinct number―5

index size=2*5*(2 1.7) 537351*(7 5.5 6)=9941030



结果出来了,index2: (closed,category,ends,approve_status)的索引最小



我们再来看一下语句

SELECT * FROM (SELECT T1.*, rownum as linenum FROM (SELECT a.* FROM auction_auctions a WHERE a.category like '18%' AND a.closed='0' AND ends > sysdate AND (a.approve_status>=0) ORDER BY a.ends) T1 WHERE rownum <18681) WHERE linenum >= 18641;

可以看出这个sql语句有很大优化余地,首先最里面的结果集SELECT a.* FROM auction_auctions a WHERE a.category like '18%' AND a.closed='0' AND ends > sysdate AND (a.approve_status>=0) ORDER BY a.ends,这里的话会走index range scan,然后table scan by rowid,这样的话如果符合条件的数据多的话相当耗资源,我们可以改写成

SELECT a.rowid FROM auction_auctions a WHERE a.category like '18%' AND a.closed='0' AND ends > sysdate AND (a.approve_status>=0) ORDER BY a.ends

这样的话最里面的结果集只需要index fast full scan就可以完成了,再改写一下得出以下语句



select * from auction_auctions where rowid in (SELECT rid FROM (

SELECT T1.rowid rid, rownum as linenum FROM

(SELECT a.rowid FROM auction_auctions a WHERE a.category like '18%' AND a.closed='0' AND ends > sysdate AND

(a.approve_status>=0) ORDER BY a.ends) T1 WHERE rownum < 18681) WHERE linenum >= 18641)



下面我们来测试一下这个索引的查询开销



select * from auction_auctions where rowid in (SELECT rid FROM (

SELECT T1.rowid rid, rownum as linenum FROM

(SELECT a.rowid FROM auction_auctions a WHERE a.category like '18%' AND a.closed='0' AND ends > sysdate AND

(a.approve_status>=0) ORDER BY a.closed,a.ends) T1 WHERE rownum < 18681) WHERE linenum >= 18641)

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=18698 Card=18344 Byt

es=21224008)



1 0 NESTED LOOPS (Cost=18698 Card=18344 Bytes=21224008)

2 1 VIEW (Cost=264 Card=18344 Bytes=366880)

3 2 SORT (UNIQUE)

4 3 COUNT (STOPKEY)

5 4 VIEW (Cost=264 Card=18344 Bytes=128408)

6 5 SORT (ORDER BY STOPKEY) (Cost=264 Card=18344 Byt

es=440256)



7 6 INDEX (FAST FULL SCAN) OF 'IDX_AUCTION_BROWSE'

(NON-UNIQUE) (Cost=159 Card=18344 Bytes=440256)



8 1 TABLE ACCESS (BY USER ROWID) OF 'AUCTION_AUCTIONS' (Cost

=1 Card=1 Bytes=1137)



Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

2080 consistent gets

1516 physical reads

0 redo size

114840 bytes sent via SQL*Net to client

56779 bytes received via SQL*Net from client

438 SQL*Net roundtrips to/from client

2 sorts (memory)

0 sorts (disk)

40 rows processed



可以看到consistent gets从19437降到2080,physical reads从18262降到1516,查询时间也丛4秒左右下降到0。5秒,可以来说这次sql调整取得了预期的效果。



又修改了一下语句,



SQL> select * from auction_auctions where rowid in

2 (SELECT rid FROM (

3 SELECT T1.rowid rid, rownum as linenum FROM

4 (SELECT a.rowid FROM auction_auctions a

5 WHERE a.category like '18%' AND a.closed='0' AND ends > sysdate AND

a.approve_status>=0

6 7 ORDER BY a.closed,a.category,a.ends) T1

8 WHERE rownum < 18600) WHERE linenum >= 18560) ;



40 rows selected.



Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=17912 Card=17604 Byt

es=20367828)



1 0 NESTED LOOPS (Cost=17912 Card=17604 Bytes=20367828)

2 1 VIEW (Cost=221 Card=17604 Bytes=352080)

3 2 SORT (UNIQUE)

4 3 COUNT (STOPKEY)

5 4 VIEW (Cost=221 Card=17604 Bytes=123228)

6 5 INDEX (RANGE SCAN) OF 'IDX_AUCTION_BROWSE' (NON-

UNIQUE) (Cost=221 Card=17604 Bytes=422496)



7 1 TABLE ACCESS (BY USER ROWID) OF 'AUCTION_AUCTIONS' (Cost

=1 Card=1 Bytes=1137)



Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

550 consistent gets

14 physical reads

0 redo size

117106 bytes sent via SQL*Net to client

56497 bytes received via SQL*Net from client

436 SQL*Net roundtrips to/from client

1 sorts (memory)

0 sorts (disk)

40 rows processed



在order by里加上索引前导列,消除了

6 5 SORT (ORDER BY STOPKEY) (Cost=264 Card=18344 Byt

es=440256)

,把consistent gets从2080降到550






本站声明
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn

热AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover

AI Clothes Remover

用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool

Undress AI Tool

免费脱衣服图片

Clothoff.io

Clothoff.io

AI脱衣机

Video Face Swap

Video Face Swap

使用我们完全免费的人工智能换脸工具轻松在任何视频中换脸!

热工具

记事本++7.3.1

记事本++7.3.1

好用且免费的代码编辑器

SublimeText3汉化版

SublimeText3汉化版

中文版,非常好用

禅工作室 13.0.1

禅工作室 13.0.1

功能强大的PHP集成开发环境

Dreamweaver CS6

Dreamweaver CS6

视觉化网页开发工具

SublimeText3 Mac版

SublimeText3 Mac版

神级代码编辑软件(SublimeText3)

深度解读:为何Laravel速度慢如蜗牛? 深度解读:为何Laravel速度慢如蜗牛? Mar 07, 2024 am 09:54 AM

Laravel是一款广受欢迎的PHP开发框架,但有时候被人诟病的就是其速度慢如蜗牛。究竟是什么原因导致了Laravel的速度不尽如人意呢?本文将从多个方面深度解读Laravel速度慢如蜗牛的原因,并结合具体的代码示例,帮助读者更深入地了解此问题。1.ORM查询性能问题在Laravel中,ORM(对象关系映射)是一个非常强大的功能,可以让

解码Laravel性能瓶颈:优化技巧全面揭秘! 解码Laravel性能瓶颈:优化技巧全面揭秘! Mar 06, 2024 pm 02:33 PM

解码Laravel性能瓶颈:优化技巧全面揭秘!Laravel作为一款流行的PHP框架,为开发者提供了丰富的功能和便捷的开发体验。然而,随着项目规模增大和访问量增加,我们可能会面临性能瓶颈的挑战。本文将深入探讨Laravel性能优化的技巧,帮助开发者发现并解决潜在的性能问题。一、数据库查询优化使用Eloquent延迟加载在使用Eloquent查询数据库时,避免

C++ 程序优化:时间复杂度降低技巧 C++ 程序优化:时间复杂度降低技巧 Jun 01, 2024 am 11:19 AM

时间复杂度衡量算法执行时间与输入规模的关系。降低C++程序时间复杂度的技巧包括:选择合适的容器(如vector、list)以优化数据存储和管理。利用高效算法(如快速排序)以减少计算时间。消除多重运算以减少重复计算。利用条件分支以避免不必要的计算。通过使用更快的算法(如二分搜索)来优化线性搜索。

Golang的gc优化策略探讨 Golang的gc优化策略探讨 Mar 06, 2024 pm 02:39 PM

Golang的垃圾回收(GC)一直是开发者们关注的一个热门话题。Golang作为一门快速的编程语言,其自带的垃圾回收器能够很好地管理内存,但随着程序规模的增大,有时候会出现一些性能问题。本文将探讨Golang的GC优化策略,并提供一些具体的代码示例。Golang中的垃圾回收Golang的垃圾回收器采用的是基于并发标记-清除(concurrentmark-s

Laravel性能瓶颈揭秘:优化方案大揭秘! Laravel性能瓶颈揭秘:优化方案大揭秘! Mar 07, 2024 pm 01:30 PM

Laravel性能瓶颈揭秘:优化方案大揭秘!随着互联网技术的发展,网站和应用程序的性能优化变得愈发重要。作为一款流行的PHP框架,Laravel在开发过程中可能会面临性能瓶颈。本文将探讨Laravel应用程序可能遇到的性能问题,并提供一些优化方案和具体的代码示例,让开发者能够更好地解决这些问题。一、数据库查询优化数据库查询是Web应用中常见的性能瓶颈之一。在

优化WIN7系统开机启动项的操作方法 优化WIN7系统开机启动项的操作方法 Mar 26, 2024 pm 06:20 PM

1、在桌面上按组合键(win键+R)打开运行窗口,接着输入【regedit】,回车确认。2、打开注册表编辑器后,我们依次点击展开【HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorer】,然后看目录里有没有Serialize项,如果没有我们可以单击右键Explorer,新建项,并将其命名为Serialize。3、接着点击Serialize,然后在右边窗格空白处单击鼠标右键,新建一个DWORD(32)位值,并将其命名为Star

Vivox100s参数配置大揭秘:处理器性能如何优化? Vivox100s参数配置大揭秘:处理器性能如何优化? Mar 24, 2024 am 10:27 AM

Vivox100s参数配置大揭秘:处理器性能如何优化?在当今科技飞速发展的时代,智能手机已经成为我们日常生活不可或缺的一部分。作为智能手机的一个重要组成部分,处理器的性能优化直接关系到手机的使用体验。Vivox100s作为一款备受瞩目的智能手机,其参数配置备受关注,尤其是处理器性能的优化问题更是备受用户关注。处理器作为手机的“大脑”,直接影响到手机的运行速度

Oracle实例数量与数据库性能关系 Oracle实例数量与数据库性能关系 Mar 08, 2024 am 09:27 AM

Oracle实例数量与数据库性能关系Oracle数据库是业界知名的关系型数据库管理系统之一,广泛应用于企业级的数据存储和管理中。在Oracle数据库中,实例是一个非常重要的概念。实例是指Oracle数据库在内存中的运行环境,每个实例都有独立的内存结构和后台进程,用于处理用户的请求和管理数据库的操作。实例数量对于Oracle数据库的性能和稳定性有着重要的影响。

See all articles