database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
ㆍSybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
Sybase Q&A 2425 게시물 읽기
No. 2425
어느 경우가 성능에 더 효율적일까요?
작성자
karerina
작성일
2009-03-02 17:43
조회수
8,012

프로시저에서


인덱스를 타는 테이블이 logical reads: (regular=1400 apf=0 total=1400) 이렇게 가져 옵니다.


그리고 인덱스를 타지 않고 FULL SCAN 하는 녀석은 logical reads: (regular=8 apf=0 total=8) 이렇게 가져 옵니다.


인덱스를 타면서 다수의 데이타를 읽는게 좋을까요 아니면 인덱스를 타지는 않지만 필요한 정보만 가져오는 구문이 좋을까요?


물론 같은 테이블이고 인덱스를 탈때는 부정 연산자를 사용 하였으며 Full scan 타는 경우는 not exists를 사용 하였습니다.


아..8이나 1400이나 차이가 별로 없을까요?

이 글에 대한 댓글이 총 3건 있습니다.

update index statistics table_name 을 수행후 다시 테스트 해보세요.


1. 일단 io가 적은게 좋겠지요

   시용자가 느끼는 시간상 1400하고 8하고는 큰차이가 없습니다.

   하지만 1400/8 배의 성능 차이겠지요.(자주 사용되는 쿼리는 cpu 사용률을 많이 올리겠지요)

2. 그런데 full scan이 8인데.. 인덱스를 타면 1400? 이거는 거의 불가능한 경우인데?

    왜 이렇게 나오는지 원인을 먼저 찾아야 하겠지요

    반대일것 같은데요....


참 update index statistics table_name 을 한후에는 sp_recompile table_name을 한후 

procedure를 실행하세요....

dd님이 2009-03-03 12:18에 작성한 댓글입니다.
이 댓글은 2009-03-03 13:51에 마지막으로 수정되었습니다. Edit

Full scan 할 때 physical io가 발생한게 아닐까요? ㅡㅡ

logical io만 기술해 주셨네요...ㅡㅡ;

 

다다님이 2009-03-06 14:26에 작성한 댓글입니다. Edit

경우에 따라서는 인덱스를 타지 않는게 더 빠를 수도 있습니다.



예를 들면 한 10000건이 있는데



한 1000건을 찾기 위해



select name,number from Table where name like '김씨%'


index key name




인덱스를 타면 인덱스에서 김씨를 찾아서 다시 그 해당하는 row를 찾고


이작업을 1000번 반복을 해야 하는데



이것보다 table scan이 더 빠를수도 있고요.



위의 쿼리의 경우 index key를 name하고 number하고 composite key로 구성하심 무지 빠르겠죠

지연님이 2009-03-19 20:38에 작성한 댓글입니다. Edit
[Top]
No.
제목
작성자
작성일
조회
2428인덱스 크기는 어느정도가 좋을까요? [1]
karerina
2009-03-04
8260
2427CASE 문 질문입니다 [4]
나그네
2009-03-03
9386
2426한글 구분을 잘 못 해요 -.- [1]
숑숑
2009-03-03
8088
2425어느 경우가 성능에 더 효율적일까요? [3]
karerina
2009-03-02
8012
2424아..log scan 봐도 모르겠어요.. [1]
karerina
2009-03-02
7872
2423load table 시 default 값을 지정가능한가요? [2]
최월자
2009-03-02
8810
2422Sybase에서 최대 세션수 정보를 가져올수 있는지요 [3]
김선희
2009-02-27
8096
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.019초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다