Index setzen?

[tsteinmaurer]

Zitat:

Man kann die Verwendung des Indizes so 'ermöglichen'

Die Verwendung eines Index ist nicht immer gleichbedeutend mit schneller.

[jobo]

@NicoDE/TE
Es gibt viele Fragen zu dem Thema, wie kann ich eine Indexverwendung erzwingen. Diese Fragen stellen sich zu Recht, wenn der Optimizer aus verschiedensten Gründen zu falschen Annahmen kommt. Dafür gibt es einerseits dann "Tricks", ich sag mal, um den Optimizer zu "übertölpeln" andererseits sogar Implementierungen mit spezielle Notation (meist herstellerspezifisch), denn die Hersteller wissen, dass es manchmal sinnvoll sein kann.

Wenn die Aufgabe aber lautet:
"Zähle alle Daten der Tabelle" (ohne Einschränkung/Where Clause/ Join Einschränkung) kommt der Optimizer zu Recht zu dem Schluss: Wenn ich eh alle Daten zählen muss, kann ich das auch "ganz bequem" von Anfang bis Ende mit einem (1!) Fulltablescan machen.
Der Zwang zum Index würde dazu führen, dass "die arme Engine" je Index Eintrag durch die Tabelle hüpfen muss, um am Ende zu dem überall mal hingesprungen zu sein und zu dem gleichen Ergebnis zu kommen, wie bei einem Fulltablescan ohne Index.

Dabei unberücksichtigt sind natürlich spezielle Indexverfahren oder aber auch die bereits gecachten Tabellenbestandteile. Letztere könnten dem Optimizer bspw. sagen, ich hab eh 90% der Daten im Cache, die 10% lade ich auch noch. Dann ist ein Fulltablescan (plus ggF. Sortierung) lediglich "Kopfrechnen" und sowieso vorzuziehen. Der Ausgang dieser Optimizerentscheidung wird wiederum von der Größe der Tabelle und der Cachegröße und der Häufigkeit der Verwendung der Tabelle abhängen.
Es gibt eine Fülle solcher Kriterien, die es oft schwierig machen, Optimizerentscheidungen nachzuvollziehen- auch sehr unterschiedlich je Produkt und Version.
Hier ist die Sache aber finde ich relativ klar.

Der Ansatz mit Trigger ist relativ naheliegend, auch wenn er noch ausgefeilt werden müsste. Wie mkinzler schon betont hat, der "Impakt" einer solchen Lösung dürfte auch bei relativ hoher Buchungsfrequenz bedeutend geringer ausfallen, als der Aufwand der hochfrequenten Fullscan-Abfragen.

[tsteinmaurer]

Zitat:

Also sieht es so aus als ob es genau umgekehrt ist, sobald ich ihn zwinge keinen Index zu verwenden dann wirds schneller!

Habe ich dir in meinem ersten Posting schon gesagt

Bei einem Full-Table-Scan wird dann halt die Response-Time variieren, abhängig davon wie die Caches (OS Filesystem, Firebird Page Cache) befüllt sind. Des weiteren auch, ob Firebird für die implizite Sortieroperation bei einem GROUP BY für temporäre Sachen auf die Disk gehen muss oder alles in den konfigurierten RAM bringt.

[Gruber_Hans_12345]

Zitat von tsteinmaurer:

Zitat:

Also sieht es so aus als ob es genau umgekehrt ist, sobald ich ihn zwinge keinen Index zu verwenden dann wirds schneller!

Habe ich dir in meinem ersten Posting schon gesagt

Bei einem Full-Table-Scan wird dann halt die Response-Time variieren, abhängig davon wie die Caches (OS Filesystem, Firebird Page Cache) befüllt sind. Des weiteren auch, ob Firebird für die implizite Sortieroperation bei einem GROUP BY für temporäre Sachen auf die Disk gehen muss oder alles in den konfigurierten RAM bringt.

Ja stimmt
Für die zeiten führe ich immer zuerst 1-2 mal die Abfrage aus ohne zu messen und dann nehme ich das mittel aus 3-5 abfragen damit ich Last die durch andere verursacht werden nicht so sehr ins Gewicht fallen.

Aber schön das ich endlich mal ein Beispiel finde (aus der Praxis), wo ein Index (der zwar für andere Sachen wichtig ist) so richtig kontraproduktiv ist.

[tsteinmaurer]

Beim Testen nicht vergessen, dass auch alle Datensätze gefetched werden und nicht nur Top X, z.b. durch ein Daten-Grid. Das kann den Unterschied Index vs. Full-Table Scan nochmal anders darstellen

[NicoDE]

Zitat von tsteinmaurer:

Die Verwendung eines Index ist nicht immer gleichbedeutend mit schneller.

Ich habe mich nur daran gestört, dass es 'nicht möglich' sein soll
(die vorherigen Beiträge erklären ja sehr ausführlich, ob und wie die Indizes benutzt werden können)