![]() |
Datenbank: Firebird • Version: 4 • Zugriff über: UniDAC
Firebird - Temporärer Index
Hallo zusammen,
weiß jemand ob es in Firebird die Möglichkeit gibt einen temporären Index zu verwenden. Also nur innerhalb einer stored procedure oder execute block? Ich habe eine stored procedure die deutlich schneller wäre wenn ich einen bestimmten Index hätte für ein paar Tabellen. Grundsätzlich ist dieser Index jedoch nicht wirklich nötig. |
AW: Firebird - Temporärer Index
Hast Du mal versucht einen View auf die Tabelle zu erzeugen und den benötigten Index auf diesen View zu setzen? Die stored procedure müßte dann auf den View zugreifen und nicht auf die Tabelle dahinter...
|
AW: Firebird - Temporärer Index
Wie kann man denn für eine View einen Index erstellen?
|
AW: Firebird - Temporärer Index
Wüsste nicht, dass das unter FireBird möglich ist.
|
AW: Firebird - Temporärer Index
Zitat:
Wenn Du eine SP ausführst, könntest Du dort: a) eine (temporäre) Tabelle anlegen, die b) bereits Daten zusammenführt / minimiert und dort c) anschließend selbst einen Index für erstellen. dann d) die eigentlichen Abfrage fahren e) die Tabelle aus a) und damit automatisch auch den Index löschen. In jedem Fall gilt, ein "temporärer" Index muss jedes Mal erstellt werden. Das kostet Zeit, die sich nur für sehr aufwändige Abfragen lohnen würde. |
AW: Firebird - Temporärer Index
Wie sieht es denn aus mit Index generell auf INACTIVE setzen und nur innerhalb der Procedure auf ACTIVE.
Kann das zu Problemen führen? |
AW: Firebird - Temporärer Index
Zitat:
![]() Zitat:
Bis bald... Thomas |
AW: Firebird - Temporärer Index
Die Tabelle in der die stored Procedure immer wieder sucht ist schon sehr groß ca. 1 Million Datensätze.
Problem ist nur das ich nicht den Primärschlüssel zum suchen verwenden kann. Die Procedure sucht im Schnitt so grob 100 Einträge in dieser großen Tabelle und das ist sehr langsam nicht indiziert. Ohne Index ca. 6 Sekunden Mit Index 32 ms Das Ding ist einfach nur das ich die Indices eigentlich nur für den Fall brauche und sonst eigentlich nicht. Die Infos zum Index aktivieren und deaktivieren habe ich bereits gelesen. Ich würde das aber gerne nur für die Connection oder Transaction machen. Nicht das ich den Index aktiviere und am Ende nicht wieder deaktivieren kann weil eine andere Connection den Index verwendet. Da weiß ich nicht wie sich das verhält und wollte wissen ob da evtl. jemand Erfahrung mit hat. |
AW: Firebird - Temporärer Index
Zitat:
Bis bald... Thomas |
AW: Firebird - Temporärer Index
Klar, könnte man zu Beginn in der SP einen INDEX erstellen und am Ende wieder löschen.
Wenn es knallt, wird es auch automatisch wieder zurückgerollt. (denk ich mal) Man könnte auch eine TempTable in der SP erstellen und füllen. Aber * ist das Erstellen des Index dann wirklich schneller, als der langsame Zugriff? * wäre es wirklich so schlimm, wenn der "nötige" Index immer bestehen bleibt? |
AW: Firebird - Temporärer Index
Du kannst es vllt in eine temporäre Tabelle (deren Inhalt nur für eine Transaction oder Connection sichtbar ist) reinschrieben, die den Index hat, den Du brauchst
|
AW: Firebird - Temporärer Index
Zitat:
|
AW: Firebird - Temporärer Index
Ich mach den Index jetzt einfach generell rein und fertig.
Andere Statements leiden darunter nicht und auch Massen-Inserts sind nicht langsamer. Also schadet der nicht und für meine Procedure hilft er ungemein. :thumb: |
AW: Firebird - Temporärer Index
Zitat:
|
AW: Firebird - Temporärer Index
Zitat:
|
AW: Firebird - Temporärer Index
Normalerweise kostet ein Index nicht so viel, dass sich weitere Optimierung lohnen würde.
Aber wenn wenige bestimmte Datensätze eine besonderer Bedeutung haben, kann man sich z.B. als Ersatz für ein Boolean-Feld auch eine Hilfstabelle anlegen, die nur die ID dieser Datensätze enthält. Die kann z.B. einfach durch einen Trigger gefüllt werden, wenn Datensätze eingefügt oder geändert werden. Eine View stellt das Ergebnis einer Abfrage auf die Hilfstabelle mit Left-Join zur Haupttabelle dar. |
AW: Firebird - Temporärer Index
kosten vom zusätzlichen index entstehen nur beim schreiben der datensätze via insert/update/delete, wenn da also nicht endlos drauf geschrieben wird, ist der mehraufwand vernachlässigbar. soll aber nicht heissen, das man bei einer tabelle mit 100 feldern einfach mal auf verdacht 100 einzelfeld indizes ascending und zur sicherheit noch 100 einzelfeld indizes descending anlegt. das wird man auf jeden fall merken und ist offensichtlicher mumpitz.
Index auf views gibt es nicht, wurde hier aber ja auch schon korrekt erkannt. wenn es sinnvoll ist, kann man sich in der ibexpert demo db mal anschauen, wie man eine materialized view nachbilden kann (ist in der datenbank als V_TOP100SALES eingebaut), dessen daten zB großen datenmenge zusammenfassen, der aber schreibend nur on demand maximal ein mal pro minute neu berechnet wird, hatte ich auch in unseren ibexpertise youtube stammtisch videos mal erklärt. Das oracle konzept des materialized views hatte einen kunden schon mal wegen der einstellung on commit statt on demand in extreme probleme gebracht (die hatte den view deklariert, wir haben da nur jede nacht ca 10000 inserts/updates/deletes gemacht die von einer firebird db kamen und aufgrund der langen leitung zum oracle server sehr oft committed werden mussten, war mit odbc und ibescript zwischen firebird und oracle ganz einfach, bis irgendjemand von denen da ein halbes jahr später den view angelegt hatte, der dann parallel 10000 neuberechnungen ausgelöst hatte und morgens stundenlang keiner mehr arbeiten konnte. da wir nur nachts daten senden, hatte der damit tagsüber noch kein problem .... Index aktivieren/deaktivieren geht zwar, frisst während dieser zeit zum aktivieren aber sehr viel I/O Last und je nach fb version und hardware kann das eine doofe idee sein meine tip wie schon von dir gewählt weg: leg den index an und lass den an, wen störts ... |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:11 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz