informixテーブルの良いインデックスを構築するのに役立つ

Question

私は3000万行のデータベーステーブルを持つ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) 
); 

がお互いに1つの非常に類似している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を最適化するためにUPDATE STATISTICS HIGH FOR TABLE ppdを2週間ごとに実行する必要がありましたが、これは良い解決策ではありません。

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出力）。統計の更新を維持することは重要ですが、オプティマイザがインデックスを使用できない場合は役立ちません。実際、この場合、インデックスは非生産的です。彼らはスペースを取って、行が挿入、更新、削除されるとシステムによるメンテナンスが必要ですが、クエリの実行時には使用されません。一意制約を強制するため、またはクエリを高速化するためにインデックスを追加します。インデックスがどちらの目的にも使用されていない場合は、無意味です（削除する方が良いでしょう）。

インデックスが一意ではないことも心配です。これは、テーブルに定義された主キーがないことを意味します。あなたは1つ持っている必要があります。

パフォーマンスに影響を与えるその他の要因は複数あります。この他のテーブルはどれですか？タイプがCHAR(100)の5つの列と、それ以外の数の適度な数の列があります。行サイズは794バイトです。つまり、Informixがシステム上で2Kページを使用する場合（ページあたり5行、4Kページサイズで）、ページに2行しか収まらないことを意味します。それらはすべて物事を簡素化する固定サイズのフィールドです。しかし、これらは「遅いSQLのように見えるもの」に比べて非常に多くの副次的な問題です。もちろん、他の索引付けされていない表と結合している場合、その組み合わせはパフォーマンスにとって致命的となる可能性があります。