백엔드 개발 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 기반 앱

AI Clothes Remover

AI Clothes Remover

사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

AI Hentai Generator

AI Hentai Generator

AI Hentai를 무료로 생성하십시오.

뜨거운 도구

메모장++7.3.1

메모장++7.3.1

사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전

SublimeText3 중국어 버전

중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기

스튜디오 13.0.1 보내기

강력한 PHP 통합 개발 환경

드림위버 CS6

드림위버 CS6

시각적 웹 개발 도구

SublimeText3 Mac 버전

SublimeText3 Mac 버전

신 수준의 코드 편집 소프트웨어(SublimeText3)

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 am 09:54 AM

Laravel은 널리 사용되는 PHP 개발 프레임워크이지만 달팽이처럼 느리다는 비판을 받기도 합니다. Laravel의 만족스럽지 못한 속도의 정확한 원인은 무엇입니까? 이 기사에서는 Laravel이 달팽이처럼 느린 이유를 여러 측면에서 심층적으로 설명하고 이를 특정 코드 예제와 결합하여 독자가 이 문제를 더 깊이 이해할 수 있도록 돕습니다. 1. ORM 쿼리 성능 문제 Laravel에서 ORM(Object Relational Mapping)은 매우 강력한 기능입니다.

Laravel 성능 병목 현상 디코딩: 최적화 기술이 완전히 공개되었습니다! Laravel 성능 병목 현상 디코딩: 최적화 기술이 완전히 공개되었습니다! Mar 06, 2024 pm 02:33 PM

Laravel 성능 병목 현상 디코딩: 최적화 기술이 완전히 공개되었습니다! 인기 있는 PHP 프레임워크인 Laravel은 개발자에게 풍부한 기능과 편리한 개발 경험을 제공합니다. 그러나 프로젝트 규모가 커지고 방문 횟수가 늘어나면서 성능 병목 현상에 직면할 수도 있습니다. 이 기사에서는 개발자가 잠재적인 성능 문제를 발견하고 해결하는 데 도움이 되는 Laravel 성능 최적화 기술을 탐구합니다. 1. Eloquent 지연 로딩을 사용한 데이터베이스 쿼리 최적화 Eloquent를 사용하여 데이터베이스를 쿼리할 때 다음을 피하세요.

C++ 프로그램 최적화: 시간 복잡도 감소 기술 C++ 프로그램 최적화: 시간 복잡도 감소 기술 Jun 01, 2024 am 11:19 AM

시간 복잡도는 입력 크기를 기준으로 알고리즘의 실행 시간을 측정합니다. C++ 프로그램의 시간 복잡성을 줄이는 팁에는 데이터 저장 및 관리를 최적화하기 위한 적절한 컨테이너(예: 벡터, 목록) 선택이 포함됩니다. Quick Sort와 같은 효율적인 알고리즘을 활용하여 계산 시간을 단축합니다. 여러 작업을 제거하여 이중 계산을 줄입니다. 불필요한 계산을 피하려면 조건부 분기를 사용하세요. 이진 검색과 같은 더 빠른 알고리즘을 사용하여 선형 검색을 최적화합니다.

Laravel 성능 병목 현상 공개: 최적화 솔루션 공개! Laravel 성능 병목 현상 공개: 최적화 솔루션 공개! Mar 07, 2024 pm 01:30 PM

Laravel 성능 병목 현상 공개: 최적화 솔루션 공개! 인터넷 기술이 발전함에 따라 웹사이트와 애플리케이션의 성능 최적화가 점점 더 중요해지고 있습니다. 널리 사용되는 PHP 프레임워크인 Laravel은 개발 프로세스 중에 성능 병목 현상에 직면할 수 있습니다. 이 문서에서는 Laravel 애플리케이션이 직면할 수 있는 성능 문제를 살펴보고 개발자가 이러한 문제를 더 잘 해결할 수 있도록 몇 가지 최적화 솔루션과 특정 코드 예제를 제공합니다. 1. 데이터베이스 쿼리 최적화 데이터베이스 쿼리는 웹 애플리케이션의 일반적인 성능 병목 현상 중 하나입니다. 존재하다

WIN7 시스템의 시작 항목을 최적화하는 방법 WIN7 시스템의 시작 항목을 최적화하는 방법 Mar 26, 2024 pm 06:20 PM

1. 바탕화면에서 키조합(Win키 + R)을 눌러 실행창을 연 후, [regedit]를 입력하고 Enter를 눌러 확인하세요. 2. 레지스트리 편집기를 연 후 [HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorer]를 클릭하여 확장한 다음 디렉터리에 Serialize 항목이 있는지 확인합니다. 없으면 탐색기를 마우스 오른쪽 버튼으로 클릭하고 새 항목을 생성한 다음 이름을 Serialize로 지정합니다. 3. 그런 다음 직렬화를 클릭한 다음 오른쪽 창의 빈 공간을 마우스 오른쪽 버튼으로 클릭하고 새 DWORD(32) 비트 값을 만들고 이름을 Star로 지정합니다.

Oracle 인스턴스 수와 데이터베이스 성능 간의 관계 Oracle 인스턴스 수와 데이터베이스 성능 간의 관계 Mar 08, 2024 am 09:27 AM

Oracle 인스턴스 수와 데이터베이스 성능 간의 관계 Oracle 데이터베이스는 업계에서 잘 알려진 관계형 데이터베이스 관리 시스템 중 하나이며 엔터프라이즈 수준의 데이터 저장 및 관리에 널리 사용됩니다. Oracle 데이터베이스에서 인스턴스는 매우 중요한 개념입니다. 인스턴스는 메모리 내 Oracle 데이터베이스가 실행되는 환경을 의미합니다. 각 인스턴스는 사용자 요청을 처리하고 데이터베이스 작업을 관리하는 데 사용되는 독립적인 메모리 구조와 백그라운드 프로세스를 갖습니다. 인스턴스 수는 Oracle 데이터베이스의 성능과 안정성에 중요한 영향을 미칩니다.

Vivox100s 매개변수 구성 공개: 프로세서 성능을 최적화하는 방법은 무엇입니까? Vivox100s 매개변수 구성 공개: 프로세서 성능을 최적화하는 방법은 무엇입니까? Mar 24, 2024 am 10:27 AM

Vivox100s 매개변수 구성 공개: 프로세서 성능을 최적화하는 방법은 무엇입니까? 오늘날 급속한 기술 발전 시대에 스마트폰은 우리 일상생활에서 없어서는 안 될 부분이 되었습니다. 스마트폰의 중요한 부분인 프로세서의 성능 최적화는 휴대폰의 사용자 경험과 직접적인 관련이 있습니다. 주목받는 스마트폰인 Vivox100s의 매개변수 구성은 많은 관심을 끌었으며, 특히 프로세서 성능의 최적화는 사용자들의 많은 관심을 끌었습니다. 휴대폰의 "두뇌"인 프로세서는 휴대폰의 실행 속도에 직접적인 영향을 미칩니다.

See all articles