Rendelés-szám indexelése firebird-ben

Rendelés-szám indexelése firebird-ben
2015-05-11T00:12:03+02:00
2015-07-21T12:26:08+02:00
2022-12-02T17:15:41+01:00
mandula
Sziasztok!
Adott ez a Stored procedure:

CREATE OR ALTER PROCEDURE SP_RENDELES_DB returns (db integer) as begin Select count(*) from rendeles where (mikorra < current_timestamp) and (teljesult is null) into :DB; suspend; end^
A kérdés csak az, milyen indexet hozzak létre hozzá?
A helyett, hogy külön 1-1:
 mikorra DESC
 teljesult ASC
indexet, helyette nem kellene / lehetne 1 db összetettet úgy, hogy akkor is gyors legyen, mikor majd már 100.000 rendelésből kell leválogatnia az aktuális 10-et?
Mutasd a teljes hozzászólást!
Az az érzésem, magamnak kell ezt kikísérleteznem, hogy mikor fut le a leggyorsabban...

A tippem az, hogy egy kettős index lenne a nyerő:

CREATE INDEX IDX_AKTIV_RENDELES_DB ON RENDELES (attoltve,teljesult) ;

De az expression formátummal is szemezgetek...
(computed by...)
Mutasd a teljes hozzászólást!

  • Az index változtatás helyett inkább egy plusz feltételt kellene bevezetni a mikor mezőre , hogy milyen időpontnál régebbi rekordokat nem vizsgálunk, vagy ami még jobb egy plusz mezőt felvenni ami jelzi hogy az adott rekord aktuális e még, ez leszűkítené a keresési halmazt.
    Mutasd a teljes hozzászólást!
  • Lehet, hogy én nem értem, amit mondani akarsz, de ez:
    1.
    (mikorra < current_timestamp)

    pontosan azt csinálja, hogy leszűkíti arra a néhány rekordra

    2.
    (teljesult is null)

    pedig meghatározza, "hogy az adott rekord aktuális e még".
    Így minek kellene még 2x ugyanez?
    A firebird nem is nagyon használja azokat az indexeket, ahol van 100.000db ="0" és 20db ="1"
    A TimeStamp mezők sokkal jobb hatásfokkal indexelhetőek, mert kicsi a szelektivitásuk. (Plusz a NULL a legelejére kerül, mint "legkisebb érték".
    Lásd: Sorts
    Mutasd a teljes hozzászólást!
  • Amikorra 100000 rendelés összegyűlik esetleg több év bizonyos hogy egyre több lesz benne a meghiúsult rendelés ami növeli az eredményhalmazodat ezért kell vagy egy alsó időkorlát vagy egy flag.
    Mutasd a teljes hozzászólást!
  • Ilyenkor inkább archiválni szokták a túl régi megrendeléseket, azaz kiveszik az éles megrendelés táblából. Meg azért 100k rekord még nem olyan sok...
    Mutasd a teljes hozzászólást!
  • Az az érzésem, magamnak kell ezt kikísérleteznem, hogy mikor fut le a leggyorsabban...

    A tippem az, hogy egy kettős index lenne a nyerő:

    CREATE INDEX IDX_AKTIV_RENDELES_DB ON RENDELES (attoltve,teljesult) ;

    De az expression formátummal is szemezgetek...
    (computed by...)
    Mutasd a teljes hozzászólást!
  • Végülis a dolog bevált, a dupla-indexet a terv szerint használja szépen a PLAN szerint.
    Bár biztosan volna még-optimálisabb megoldás, de arra csak kísérletezés útján lehetne rájönni, mert hiába olvastam ki szinte minden ide vonatkozó doksit, (az ibExpert és firebirdSQL oldalakról,) nem találtam releváns infót.

    Idővel valóban az lesz a megoldás, hogy törlöm a régi adatokat, nehogy túl nagyra dagadjon a tábla rekordszáma.

    Köszönöm mindenkinek, aki megpróbált segíteni !
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd