2012-12-13 54 views
3

我有一個表叫hitlist,其中有3列:組索引Informix中

int id 
long hitlisted_date 
long deleted_date 

我會根據這些列來查詢該表:

histlisted_date (frequent) 
hitlisted_date && deleted_date (frequent) 
deleted_date (not frequent) 

在這種情況下,什麼樣的我應該使用索引嗎?在hitlisted_date & deleted_date

  • 組指數hitlisted_date & deleted_date
  • UPDATE

    1. 單列索引表將只有1000 - 5000行。
      這些是將要使用的查詢模式。

      1)hitlisted_date BETWEEN
      2)hitlisted_date <
      3)deleted_date = -1和hitlisted_date < =
      4)deleted_date> 0

      對於上述圖案,這些索引就足夠了?

      1. CREATE INDEX i1_hitlist ON hitlist(hitlisted_date);
      2. CREATE INDEX i2_hitlist ON hitlist(deleted_date,hitlisted_date);
    +0

    請注意DATE(-1)是1899-12-30。如果一切都足夠近以至於它不會干涉,那麼你很好,但是不久前有人比一般流通中的人老。 –

    +0

    日期列是'長'數據類型(紀元時間) – cppcoder

    +0

    因此它們不是DATE類型。它們是INTEGER列。 Informix中的DATE類型具有特定的含義。 (並且1969-12-31 23:59:59比1899-12-30更近,即使如此也可能不是問題,但要小心) –

    回答

    4

    由於hitlisted_date和組合將被頻繁使用的,要在兩列組合索引與hitlisted_date第一:

    CREATE INDEX i1_hitlist ON hitlist(hitlisted_date, deleted_date); 
    

    此索引可以(並且將)是用於查詢與合適的條件在hitlisted_date自己,或兩個日期。

    您可能會發現它有利於對剛剛deleted_date第二個指標:

    CREATE INDEX i2_hitlist ON hitlist(deleted_date); 
    

    這可以被用於搜索上只是deleted_date。如果你有時做一個刪除的日期和範圍hitlisted日期搜索,那麼你可能會發現它更好地使用這就是i1_hitlist反向複合指數:

    CREATE INDEX i2_hitlist ON hitlist(deleted_date, hitlisted_date); 
    

    這是不太可能是一個幫助,但唯一可以肯定的就是嘗試一下,看看。這取決於您的查詢模式以及查詢使用的實際情況。

    hitlisted_date的指數上沒有真正的美德;它只是阻礙了優化器(因爲它必須查看兩個索引並決定哪個更好,並且因爲在插入,更新和刪除行時還有更多工作要做)。命中日期不可能是唯一索引。如果可以的話,那麼保持單列索引以及重複索引就會有單獨的原因。 (另請參閱Is an index on (A,B) redundant if there is an index on (A, B, C)。)

    更改索引後,請確保統計信息是最新的(現在或多或少都會自動更新,但過去很重要),然後使用SET EXPLAIN運行查詢以檢查正在使用索引(以及正在使用哪些索引)。

    +0

    那麼爲什麼不只是在(A,B,C)上創建一個複合索引呢?這應該涵蓋查詢的任何組合? –

    +0

    在交叉引用的問題中,(A,B,C)上已經有一個索引;問題是隻有(A,B)的索引也會有好處。答案是'不,除非(A,B)是獨特的'。 –

    +0

    幾個因素:列基數,頻繁查詢模式,nrows,rowlength,靜態或頻繁表更新等決定如何索引和列索引? –

    1
    CREATE CLUSTER INDEX clusidx ON hitlist(hitlisted_date,deleted_date); 
    CREATE   INDEX ddatidx ON hitlist(deleted_date); 
    

    如果表中有幾行,甚至都不值得索引列,但與許多行肯定。由於此表中只有3列,因此索引不會成爲大量行的問題。

    實施例:

    我有13個VARCHAR列和2列DATE一個靜態只讀表。

    rowlength = 557,nrows = 1239825。

    在7個單獨的列上進行索引,因爲沒有涉及多個列的頻繁查詢,但是如果頻繁查詢某個特定的組合列,則爲這些查詢創建組合列索引。

    +0

    'hdaidx'不會付出代價。 –

    +0

    因爲它已經包含在集羣索引中了嗎? –

    +1

    是;羣集索引可用於hdaidx可用於的任何事物。如果對於任何給定的襲擊日期將會有大量的刪除日期,那麼有時可能會更好地使用單列索引,但是對於它是有益的,這是相當不尋常的。如果表是動態的(大量活動),那麼額外的索引在更新上可能花費比在select上保存更多;如果表格幾乎是靜態的(非常小的活動),則相反可能是正確的。命中日期不可能是唯一的索引;如果可以的話,可能還有其他原因。 –