Gute Nachrichten! Das Buch „Secrets of Firebird SQL Optimizer“ ist jetzt als Vorbestellung (PDF, 420 Seiten) mit 50 % Rabatt erhältlich! Hol dir diesen unverzichtbaren Leitfaden und bring deine Fähigkeiten zur Datenbankoptimierung auf das nächste Level.
Was macht dieses Buch zu einem idealen Geschenk für jeden Firebird-Entwickler? Zwei Gründe:
Es ist die erste umfassende Ressource, die tiefe Einblicke in die interne Funktionsweise von Firebird-Abfragen bietet und dabei theoretische Konzepte mit praxisnahen Beispielen kombiniert.
100 % der Erlöse aus dem Buchverkauf werden als Provision an die Firebird Foundation gespendet und unterstützen damit direkt die Weiterentwicklung von Firebird.
Wichtig: Bitte wähle beim Kauf die Sprache sorgfältig aus. Die Sprachwahl ist endgültig und kann nicht geändert werden (z. B. kann Portugiesisch nicht nachträglich in Englisch geändert werden und umgekehrt). Achte darauf, dass der Buchtitel in der Bestellung der gewählten Sprache entspricht, z. B.: „Secrets of Firebird SQL Optimizer“ für Englisch, „Livro: Segredos do Otimizador SQL do Firebird“ für Portugiesisch, „Geheimnisse des Firebird SQL Optimizers“ für Deutsch, usw.
Wie bekommst du den Rabatt?
Klicke auf den Kauf-Link und gib den Promo-Code xmas2025book ein.
Da ich mich nicht nur mit Firebird-SQL beschäftige, sondern auch mit SQL-Server, Oracle, PostreSQL sowie DB2 for i, arbeite ich schon seit nun bald 30 Jahren auf allen Ebenen mit der Indexoptimierung.
Ich erstelle, auf Grund der Where-Klausel, bei unseren Abfragen automatische Indizes in der Firebird.
Single-Column-Indizes haben sich da eher als schlechte Wahl herausgestellt. Sogenannte compound/composite Keys arbeiten da durchaus effizienter.
Einen OrderBy lasse ich bei allen Queries inzwischen komplett weg, da man das Ergebnis i.d.R. in Objekten im Speicher hat und da schneller sortieren kann, C# Sort, Linq-Orderby, Grids auf dem Bildschirm.
Ein Index für die GroupBy-Klausel hat sich da i.Ü. genauso als unwirksam erwiesen, wenn man eine Where-Klausel verwendet. Und klar ist auch, dass man für Join-Beziehungen passende Indizes haben muss.
Das stellt unsere Software sicher, da wir nur Tabellen mit Primary-Keys joinen. Alles andere passiert wieder im Prozess und nicht in der DB.
Während eines ETL-Prozesses werden alle Query-Indizes deaktiviert um das Laden zu beschleunigen. Da kann man schon mit meinem "Bulk-Update or Insert" durchaus 5.000 - 20.000 Zeilen/Sekunde erreichen.
Nach dem ETL, der dann auch schnell vorüber ist, werden die Indizes wieder aktiviert.
Die Strategie ist daher relativ einfach, da der Optimizer durchaus in der Lage ist, Indizes auch zu kombinieren.
Jede And-Gruppe in einer Where-Klausel wird zusammen gefasst, wobei die "="-Bedingungen nach vorne sortiert werden, gefolgt von starts with, >=, <=. Like nur dann, wenn er ohne % am Anfang definiert wird, also ein Starts with ist. Eine In (...)-Abfrage wird von der FB automatisch in mehrere Abfragen aufgegliedert und kann als "=" gewertet werden. "Not in" macht da eher wieder einen Table-Scan.
Diese Automatik führt bei unseren Queries zu erheblichen Beschleunigungen der zu ladenden Daten.
Was bei der Firebird leider immer noch nicht so schön ist, dass man bei einem Index nur den gesamten Index descend definieren kann. Ein ascend/descend auf einzelnen Schlüsseln eines Compound-Keys wäre da schon mal hilfreich. Vielleicht kommts ja noch.
Statt des Buches wünsche ich mir eher, neben dem Index-Plan auch einen "empfohlenen Index" auszugeben.
Schließlich weiß der Optimizer ja, was für die Abfrage ein guter Index wäre.
Die DB2 for i (ehemals AS/400) macht sowas schon lange, wobei die auch da schon mal daneben liegt und den frischen Index dann doch nicht nimmt.
