informix 테이블에 대한 좋은 인덱스 구축에 도움이 필요합니다.

Question

3 천만 개의 행이있는 데이터베이스 테이블이있는 Informix 11.7 서버가 있습니다. 테이블 스키마는 다음과 같이이다 :이 표에

CREATE TABLE ppd (
    datum DATE, 
    obrabot INTEGER, 
    rb_obr INTEGER, 
    blag_sif_transakcija INTEGER, 
    tip_transakcija CHAR(20), 
    tabela_kod CHAR(5), 
    vrska_sif_transakcija INTEGER, 
    ekspozitura CHAR(3), 
    valuta CHAR(3), 
    iznos_p DECIMAL(20,2), 
    iznos_d DECIMAL(20,2), 
    smetka CHAR(15), 
    podsmetka CHAR(9), 
    client_id CHAR(13), 
    client_tip CHAR(1), 
    client_naziv CHAR(100), 
    adresa CHAR(100), 
    edb CHAR(13), 
    pasos CHAR(20), 
    maticen_broj CHAR(20), 
    vid_rabota CHAR(2), 
    smetka_primac CHAR(15), 
    naziv_primac CHAR(100), 
    broj_primac CHAR(20), 
    smetka_davac CHAR(15), 
    naziv_davac CHAR(100), 
    broj_davac CHAR(20), 
    edb_fl CHAR(13), 
    sifra_plakanje CHAR(6), 
    namena CHAR(100), 
    vo_valuta CHAR(3), 
    vo_iznos DECIMAL(20,2), 
    datum_vreme DATETIME YEAR TO SECOND, 
    operator CHAR(3), 
    flag INTEGER, 
    potpisnik CHAR(10) 
); 

가 서로 하나 매우 유사하다 (6 개) 인덱스, 그리고 나는 그들이 잘못 기록 된 것을 생각하고이 테이블에서 실행되는 쿼리가 그 이유는 이유 느린. 19000 행의 경우 30 분이 소요됩니다. 이 필드는 모든 인덱스에 데이텀 및 운영자 반복 볼 수 있듯이

CREATE INDEX ix_ppd_1 ON ppd (datum,operator,client_id,obrabot); 
CREATE INDEX ix_ppd_2 ON ppd (datum,operator,edb,obrabot); 
CREATE INDEX ix_ppd_3 ON ppd (datum,operator,maticen_broj,obrabot); 
CREATE INDEX ix_ppd_4 ON ppd (datum,operator,rb_obr,obrabot); 
CREATE INDEX ix_ppd_5 ON ppd (datum,operator,edb,edb_fl); 
CREATE INDEX ix_ppd_6 ON ppd (datum,operator,rb_obr,tabela_kod); 

: 여기 는 인덱스가 어떻게 생겼는지입니다. 테이블을 최적화하기 위해 누군가를 다시 작성하는 데 도움을 줄 수 있습니까?

지금까지 테이블 ppd을 최적화하기 위해 매 2 주마다 UPDATE STATISTICS HIGH FOR TABLE ppd을 실행해야했지만 좋은 해결책은 아니겠습니까?

Answer 1

쿼리에서 datum 및 operator에 조건 (동등한 조건이 바람직 함)을 지정하지 않은 경우 해당 인덱스는 쓸모가 없습니다. 서버는 전체 테이블을 검색하거나 즉석에서 인덱스를 작성해야합니다. 쿼리와 예를 들어 :

SELECT * 
    FROM ppd 
WHERE datum = DATE('2017-11-04') 
    AND operator = 'JKL' 
    AND … 

그 인덱스의 조건이 … 부분에 지정된 내용에 따라 유용 할 수있다.

조건이 datum 또는 operator이 아닌 같음을 지정하면 색인은 유용하지는 않지만 유용하지는 않습니다. WHERE operator MATCHES '*'과 같은 작업을 수행하면 색인의 이점을 얻을 수 없습니다. 예를 들어 :

는

SELECT * 
    FROM ppd 
WHERE datum BETWEEN DATE('2017-11-04') AND DATE('2017-11-08') 
    AND operator = 'JKL' 
    AND … 

옵티마이 저는 인덱스를 사용할 수 있지만 BETWEEN 절에 암시 5 날짜의 각각에 기록 된 모든 운영자 값에 대한 데이터를 선택합니다. 'JKL' 필터는 옵티마이 저가 훨씬 도움이되지 않습니다. 고정 날짜 및 운영자 범위를 사용하면 색인에서 더 많은 이점을 얻을 수 있지만 여전히 다소 제한적입니다.

당신이 같은 쿼리가 있다면 :

SELECT * 
    FROM ppd 
WHERE client_id = 'ABC123DEF456Z' 
    AND obrabot = 12345 
    AND …{no mention of datum or operator}… 

다음 인덱스의 어느 것도 전혀 사용할 수 없습니다.

따라서 느리게 실행되는 쿼리를보고 표시해야합니다. 쿼리 계획을 검토해야합니다 (SET EXPLAIN 출력). 통계를 업데이트 된 상태로 유지하는 것은 중요하지만 옵티마이 저가 인덱스를 사용할 수없는 경우 도움이되지 않습니다. 사실,이 경우 인덱스는 비생산적입니다. 이들은 행을 삽입, 갱신, 삭제할 때 공간을 차지하고 시스템 유지 보수가 필요하지만 조회가 실행될 때는 사용되지 않습니다. 고유성 제약 조건을 적용하거나 쿼리 속도를 높이기 위해 인덱스를 추가합니다. 색인이 어느 용도로든 사용되지 않으면 무의미합니다 (색인을 삭제하는 것이 좋습니다).

인덱스가 유일하지 않으므로 걱정됩니다. 즉, 테이블에 정의 된 기본 키가 없다는 의미입니다. 당신은 하나 있어야합니다.

성능에 영향을주는 다른 여러 요소가 있습니다. 어떤 다른 테이블에이 테이블에 가입합니까?유형이 CHAR(100) 인 5 개의 열과 적당한 수의 다른 열이 있습니다. 행 크기는 794 바이트입니다. 이는 Informix가 시스템에서 2K 페이지 (페이지 당 5 행과 4K 페이지 크기)를 사용하는 경우 페이지에 2 행만 맞을 수 있음을 의미합니다. 그것들은 모든 것을 고정시키는 고정 된 크기의 필드입니다. 그러나 이것들은 "느린 SQL이 어떻게 생겼는지"와 비교할 때 매우 많은 이차적 인 문제입니다. 물론 병목 현상이없는 다른 테이블과 조인하는 경우 성능이 저하 될 수 있습니다.