In einem Kunden-Projekt sollte ich die Performance der SQL-Zugriffe einer .NET-Applikation verbessern.<\/p>\n
Hier beschreibe ich die Ergebnisse, da sie sich auch auf andere Szenarien verallgemeinern lassen.<\/p>\n
Die erste Ver\u00e4nderung war, keine GUIDs<\/strong> als clustered primary keys<\/strong> zu verwenden. Stattdessen setzen wir nun ints (mit Identity) ein. Dies f\u00fchrt zu einer immensen Beschleunigung bei den INSERTs in die Datenbank. Dies ist sehr gut nachvollziehbar, da nun die INSERTs immer am Ende der Tabelle statttfinden, so dass kein zeitaufw\u00e4ndiges Umorganisieren der Seiten innerhalb der Tabelle notwendig wird.<\/p>\n Leider ging es aber in meiner Aufgabe um die SELECT-Performance und nicht um die INSERT-Performance. Aber auch diese verbesserte sich durch die Verwendung der integer-Werte deutlich (Abfragezeit ungef\u00e4hr halbiert). Als Test verwendete ich die Abfrage von 500 Datens\u00e4tzen, die ich zu Beginn zuf\u00e4llig ausgew\u00e4hlt hatte. Vor jeder Abfrage wurde nat\u00fcrlich der Cache geleert \ud83d\ude42 Die Steigerung l\u00e4sst sich dadurch erkl\u00e4ren, dass alle Indizes nun vom Platzbedarf viel kleiner wurden (1 int = 4 byte, 1 guid = 16 byte –> ca. 4x so viele Daten gehen auf eine Index-Page [nat\u00fcrlich abh\u00e4ngig von den weiteren Feldern des Index]). Au\u00dferdem ist ein Z\u00e4hler besser verteilt als eine Guid.<\/p>\n Als n\u00e4chste Verbesserung verwendete ich in m:n-Tabellen<\/strong> als clustered primary key nicht einen Z\u00e4hler, sondern einen zusammengesetzten Schl\u00fcssel<\/strong> aus den beiden referenzierten Tabellen (+ ein weiteres Feld, um die Eindeutigkeit sicherzustellen). Dabei verwendete ich als erstes Feld das Feld der beiden, das in den meisten Abfragen bekannt ist. (Auf der umgekehrten Reihenfolge lag nat\u00fcrlich auch ein Index). Dadurch muss beim Standard-Zugriff nicht mehr \u00fcber einen non-clustered Index zugegriffen werden, wodurch ein Zugriff eingespart wird. Dies brachte eine weitere Halbierung der Zugriffszeit.<\/p>\n ALs letztes gab es spezielle Szenarien, in denen nach Texten gesucht werden musste – ein Beispiel: Man m\u00f6chte alle Auftr\u00e4ge ermitteln, die in einer Position einen bestimmten Positionsfreitext enthalten. Dann wird folgendes SQL-Statement abgesetzt:<\/p>\n SELECT * FROM Auftrag a INNER JOIN Auftragsposition pos on pos.AuftragID = a.AuftragID WHERE pos.Positionsfreitext like ‚Test%‘<\/p>\n Nat\u00fcrlich war auf der Auftragspositions-Tabelle ein Index auf Positionsfreitext. Ich erweiterte diesen Index um die AuftragID. Dadurch kann der Join direkt \u00fcber den Index abgewickelt werden und ein Zugriff auf die Tabelle wird eingespart, was f\u00fcr diesen Spezialfall ebenfalls eine deutliche Performance-Steigerung einbrachte.<\/p>\n","protected":false},"excerpt":{"rendered":" In einem Kunden-Projekt sollte ich die Performance der SQL-Zugriffe einer .NET-Applikation verbessern. Hier beschreibe ich die Ergebnisse, da sie sich auch auf andere Szenarien verallgemeinern lassen. Die erste Ver\u00e4nderung war, keine GUIDs als clustered primary keys zu verwenden. Stattdessen setzen wir nun ints (mit Identity) ein. Dies f\u00fchrt zu einer immensen Beschleunigung bei den INSERTs … Performance und GUIDs<\/span> weiterlesen