열에 최대 값을 가진 행을 찾는 더 좋고/더 빠른 방법이 있습니까?

Question

INFORMIX-SE 7.32 :

나는 약 5,000 개의 Nrows가있는 트랜잭션 테이블을 가지고 있습니다. transaction.ticket_number [INT]는 특정 행이 업데이트 될 때마다 다음 순차적 티켓 번호로 업데이트되는 열입니다. 열은 고유 색인입니다. 저는 현재 최대 (transaction.ticket_num)를 찾으려면 다음 SELECT 문을 사용하고 있습니다 :

업데이트되는 행이 고객에 가입되어있는 transaction.fk_id [INT], 주문에 따라 클러스터되어 있기 때문에

SELECT MAX(transaction.ticket_number) FROM transaction; 

. pk_id [SERIAL]의 행은 물리적으로 트랜잭션 테이블의 끝에 위치하지 않고 각 특정 고객에 속한 트랜잭션 행 그룹 내에 상주합니다. 각 고객 트랜잭션을 스크롤 할 때 응답 시간이 빨라지기 때문에 각 고객의 트랜잭션을 클러스터링하기로했습니다. 위의 쿼리에서 max (transaction.ticket_number)를 찾는 더 빠른 방법이 있습니까? .. '트랜잭션의 고유 인덱스 (ticket_number) 내림차순'이 액세스를 향상 시키거나 색인이 완전히 시작되어 부적절하게 끝나는 것입니까? 때문에 등 NULLABLE 컬럼 및 기타 요인, 인덱스의 사용에

는

Answer 1

현대 컴퓨터의 행이 5000 개 밖에없는 테이블에서 다양한 기술의 성능 차이를 측정 할 수는 없지만 특히 내가 직면 한 단일 사용자 시나리오의 경우에는 그렇지 않을 수 있습니다. 5000 행이 모두 최대 허용 크기 (32KB 바로 밑)에 있더라도 160MB의 데이터를 처리하게되어 시스템의 캐시에 쉽게 맞을 수 있습니다. 실제로는 행이 훨씬 작으며 캐시의 모든 데이터가 필요하지는 않습니다.

성능상의 문제가없는 경우 티켓 번호 열의 색인으로 이동하고 서버 (Informix SE)를 사용하여 작업하십시오. 시연 가능한 문제점이있는 경우, SET EXPLAIN 출력에서 ​​조회 계획을 표시하십시오. 그러나 SE 성능을 어느 정도 조정할 수 있는지에 대한 주요 제한 사항이 있습니다. 튜닝에 대한 최소한의 요구만으로도 설치 및 이동 기술입니다.

Informix SE가 Informix Dynamic Server가 지원하는 'FIRST n'(일명 '최상위 n') 표기법을 지원하는지 확실하지 않습니다. 나는 믿지 않는다.

Answer 2

, 당신은 종종 빠른 것 다음을 찾을 수 있지만, 일반적으로 단지 negligably ...

SELECT TOP 1 ticket_number FROM transaction ORDER BY ticket_number DESCENDING 

나는 여부에 관해서는 불확실 해요 [ticket_number]에 대한 색인이 실제로 있습니까? 아니면 UNIQUE 제약이 있습니까? 제약 조건은 MAX를 결정하는 데 도움이되지 않지만 INDEX는 결정합니다. 인덱스가 제 인덱싱 열로 ticket_number 존재 이벤트에

:
- 인덱스가/조회를 탐색은 일 가능성이 경우에는 모든

에서 다른 값을 검사 할 필요가없는, 사용되는 INDEX가 ticket_number 존재하지 첫 번째 색인 열로 :
- 인덱스 스캔 가능성이 더 사용할 수 INDEX가 존재없는 경우에 인덱스

의 모든 하나의 고유 한 항목을 확인, 발생한다 :
을 - 전체 표는 것 스캔 됨