1. like 문 때문에 ref_no 인덱스를 탈수 없음

=>

1. WHERE REF_NO LIKE 'ABC%' 부분을

   WHERE REF_NO >'ABC' and REF_NO LIKE 'ABC%'  로 변경

   이런걸 허수조건이라고 합니다. 추가되는 where문은 원했던 where값을 모두 포함하는 조건이어야 합니다.

위의 분 말씀처럼 해보시고 안되시면

set showplan on하시고 나서

select문 실행해보시면

index를 타는지 안타는지 알수 있습니다.

index가 있음에도 불구하고 index를 안타는 경우는

통계table에 이상이 있는 경우로 update statistics를 돌려주시고

정상적으로 index를 타는 경우는 컬럼타입이 아마 text일 걸로 생각되는데,

그것을 performance를 좋게 한다는 것은 어려울것으로 보여집니다.

full text search option을 설치 하시면 해결됩니다.

(약 100배이상 빠르다고 하는 군요)

저도 게시판에 그거 써보려고 했는데..

게시판이 휑해서...못써봤습니다

1. 장종훈(우연을가장한인연)님이 알려주신대로 해봤는데요..

    아쉽게도 효과가 없네요...어쨌든 감솨~

2. 지연님이 말씀하신대로 set showplan on 문을 넣어서

    SELECT 해보았는데요..로그가 다음과 같이 나왔습니다...

SELECT * FROM MG_MASTER

 WHERE OUR_REF_NO >= 'NG078503001968'

      AND OUR_REF_NO LIKE 'NG078503001968%'

 ORDER BY DOC_ID 를 돌려보면

-> 로그

QUERY PLAN FOR STATEMENT 1 (at line 1).

update statistics ~ 실행 후 속도가 제법 나네요...

감솨합니다....^^

update statistics을 수행하신후 약간 좋아졌다니, 다행이긴 한데요,

update statistics을 수행한후에도 showplan이

        FROM TABLE
            MG_MASTER
        Nested iteration.
        Table Scan.

이런식으로 table scan이 돌아 간다면

뭔가가 잘못 된거 같은데요.

꼭 showplan 다시 확인 바랍니다.

만일 같은 plan이 나오면 index를 확인 해보셔야(index가 깨져 있다든가?, 아님 옵티마이져가 이상이 있다든가, 아님 원래 그쿼리가 전체 table의 20~30%이상의 data를 가지고 오는 쿼리라든지,

원인 확인을 꼭 해보세요

cache pool이 32K가 있는 것으로 봐선 시스템 사양이 좋은 것으로 보여지는데요~~

통계테이블 갱신 후 QUERY 한 겁니다...^^

QUERY PLAN FOR STATEMENT 1 (at line 1).

    STEP 1
        The type of query is DECLARE CURSOR.

QUERY PLAN FOR STATEMENT 1 (at line -1).

    STEP 1
        The type of query is OPEN CURSOR S05000000.

QUERY PLAN FOR STATEMENT 1 (at line 1).

    STEP 1
        The type of query is INSERT.
        The update mode is direct.
        Worktable1 created, in allpages locking mode, for ORDER BY.

        FROM TABLE
            MG_MASTER
        Nested iteration.
        Index : MG_MASTER_IDX2
        Forward scan.
        Positioning by key.
        Keys are:
            OUR_REF_NO  ASC
        Using I/O Size 32 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 4 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable1.

    STEP 2
        The type of query is SELECT.
        This step involves sorting.

        FROM TABLE
            Worktable1.
        Using GETSORTED
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 32 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.

QUERY PLAN FOR STATEMENT 1 (at line -1).

    STEP 1
        The type of query is CLOSE CURSOR S05000000.

QUERY PLAN FOR STATEMENT 1 (at line -1).

    STEP 1
        The type of query is DEALLOCATE CURSOR S05000000.

QUERY PLAN FOR STATEMENT 1 (at line 1).

    STEP 1
        The type of query is DECLARE CURSOR.

QUERY PLAN FOR STATEMENT 1 (at line -1).

    STEP 1
        The type of query is OPEN CURSOR S05000000.

QUERY PLAN FOR STATEMENT 1 (at line 1).

    STEP 1
        The type of query is INSERT.
        The update mode is direct.
        Worktable1 created, in allpages locking mode, for ORDER BY.

        FROM TABLE
            MG_MASTER
        Nested iteration.
        Index : MG_MASTER_IDX2
        Forward scan.
        Positioning by key.
        Keys are:
            OUR_REF_NO  ASC
        Using I/O Size 32 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 4 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable1.

    STEP 2
        The type of query is SELECT.
        This step involves sorting.

        FROM TABLE
            Worktable1.
        Using GETSORTED
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 32 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.

4 Row(s) affected

QUERY PLAN FOR STATEMENT 1 (at line -1).

    STEP 1
        The type of query is FETCH CURSOR S05000000.

이제는 정상적으로 idx2를 타는군요

그런데

cursor를 이용하시면 원래 성능이 잘안나옵니다~~~

인덱스를 타게하기 위해서 like '~~%'를

> operator로 수정을 하라고 하셨는데 이것은 잘못된 것입니다.

인덱스의 선행 컬럼인 좌변 컬럼을 변경하지 않는 경우에는 인덱스를

탈수있습니다.

Sybase는 Cost Based Optimizer이기 때문에 인덱스가 있어도

Table Scan이 비용이 보다 적게 든다고 판단하게 되면 Optimizer는

Access Method로 Table Scan을 선택할 수 있습니다.

이와같이, CBO는 인덱스가 있다고 항상 인덱스를 이용하는 것이 아니라

비용에 기반해서 Access Method를 선택하게 됩니다.

그렇게 때문에 CBO에게 정확한 판단을 내릴수 있도록

통계치 정보를 항상 최신으로 유지시켜주는 작업이 필요합니다.

수고하세요.

data님의 글..

"인덱스를 타게하기 위해서 like '~~%'를

> operator로 수정을 하라고 하셨는데 이것은 잘못된 것입니다."

그렇지 않습니다.

물론 나머지 밑의 글은 전적으로 맞고요

장종훈님 말씀대로...별의미없지는 않고요..

like를 <=등으로 바꾸시면 더 효율적인게 맞습니다

튜닝편에 나와 있던데....

인덱스 종류를 안쓰셔서, fp 인덱스로 착각했습니다.

fp인덱스의 경우면 제가말한

1. WHERE REF_NO LIKE 'ABC%' 부분을

   WHERE REF_NO >'ABC' and REF_NO LIKE 'ABC%'  로 변경

의 적용을 받습니다.

효과는 full 스켄이 일어날것을 index 스켄으로 바꾸어줍니다.

대신 select 되는 건수/전체 테이블 건수 가 현저히 높을 경우

full스켄을 유도하는것이 더유리할수 있습니다.

LF,HG 인덱스의 경우 해당사항이 없습니다.

(like 문의 뒤쪽에 %가 붙은경우 LF 인덱스는 탑니다.)

잘못된 정보를 제공해드려서 죄송합니다.

(Sybase IQ에만 해당되는 내용입니다. ASE는 인덱싱방법이 다릅니다.)

일단 인덱스를 타지 않으면 통계테이블 update 작업을 먼저 하세요
사이베이스는 위에 서 말씀하신것 처럼 cost base 입니다.

무조건 인덱스를 타게 할경우 빠른 경우도 있지먼 오히려
더 느려 질경우 발생합니다.(cost base)

그래서 억지로 하는것 보다. DB 알아서 처리 하도록 하는 게 좋습니다.
그리고 그렇게 해도 안될경우.. 데이터 양을 체크 해보세요 .
(전체의 데이터 양의 Select 해서의 데이터 양을 ... 전체의 데이터양의 20% 넘으면 아시죠... )

그리고 order by 대한 비용도 체크 해보시고 .. (이부분도 CPU ,Disk 부분을 잡아 먹습니다.)

order by 비용을 줄여 줄수 있는 방법을 체크 해보셔야 합니다.

(order by 을 index 유도)

그래도 안될경우.. Select 절과, where 절, order by 절을 인덱스 (커버드인덱스 ?) 달아 줘서 체크 해보세요..

그래도 안될경우 . 응용프로그램 및 설계부분 부터 새로 검토 해보시는게 좋을 듯 싶습니다.