SQL Server mit dem richtigen Transact SQL Code optimieren
Die Wahl des richtigen Datentyps und die Vermeidung von dynamischem SQL sind zwei der neun T-SQL-Best Practices, die Basit Farooq hier vorstellt.
SQL-Server-Datenbanken sind das Rückgrat vieler Unternehmensanwendungen. Entsprechend wichtig ist es, die Datenbank-Performance zu optimieren. Grundsätzlich gilt: Der beste Weg, um die SQL-Server-Leistung zu maximieren, ist ein guter Transact-SQL (T-SQL) Code. Daher sollten SQL-Entwickler beim Schreiben des Codes folgenden T-SQL Best Practice und Richtlinien folgen. Dieser Artikel stellt allgemeine Best Practices für T-SQL vor, um zuverlässigen, robusten und effizienten SQL-Code zu generieren.
Wählen Sie den richtigen Datentyp
Wenn Sie eine Tabelle erstellen, müssen Sie sich entscheiden, welchen Datentyp Sie für die Spaltendefinitionen verwenden. Ein Datentyp definiert bekanntlich die Art der Daten, die Anwender in einer Spalte speichern können. Datentypen verwendet man aber auch, um Variablen und Eingabe- und Ausgabeparameter für Stored Procedures festzulegen. Für jede Spalte oder Variable müssen Sie einen Datentyp entsprechend den in dieser Spalte oder Variable gespeicherten Daten auswählen.
Mehr zum Thema SQL:
SQL-Injection-Angriffe verhindern bei Outsourcing der Entwicklung.
SQL Server 2014: In-Memory OLTP, Buffer Pool- und AlwaysOn-Erweiterung.
Sieben Geheimnisse des SQL Server Management Studios für Microsoft SQL Server.
Darüber hinaus sollten Sie die Speicheranforderungen berücksichtigen und Datentypen wählen, die eine effiziente Speicherung ermöglichen. Wenn Sie zum Beispiel ganze positive Zahlen zwischen 0 und 255 speichern möchten, sollten Sie immer tinyint verwenden statt smallint, int oder bigint. tinyint ist ein festes 1-Byte-Feld, während smallint 2 Byte, int 4 Byte und bigint 8-Byte lange Felder sind.
Die Wahl des richtigen Datentyps verbessert auch die Integrität der Daten. Wenn Sie zum Beispiel einen Datetime-Datentyp für eine Datenspalte verwenden, kann in dieser Spalte nur das Datum gespeichert werden. Wenn Sie aber einen Character oder numerischen Datentyp für die Spalte definieren, lässt sich jede Art von Zeichen oder jeder numerische Datenwert in dieser Spalte speichern. Die Spalte muss dann nicht mehr nur ein Datum darstellen.
Schließlich verbessert die Wahl des richtigen Datentyps auch die Leistung, so dass sich ein korrekter Ausführungsplan ergibt.
Vermeiden Sie DISTINCT oder UNION-Klauseln
Das Platzieren von DISTINCT-Klauseln in Ihren T-SQL-Queries entfernt doppelte Zeilen aus den Ergebnissen. Wenn Sie sicher sind, dass Ihr Abfrageergebnis nur aus einer einzelnen Zeile besteht, sollten Sie DISTINCT-Klauseln vermeiden, da sie einen unnötigen Sortiervorgang auslösen.
Die UNION-Klausel fügt ebenfalls einen zusätzlichen Sortiervorgang hinzu, indem sie doppelte Datensätze aus zwei oder mehr SELECT-Anweisungen entfernt. Wenn Sie UNION verwenden, um die Ergebnisse von zwei oder mehr SELECT-Anweisungen zu kombinieren, die nur einen einzigen Datensatz enthalten, ist es besser, die UNION ALL-Klausel zu verwenden. UNION ALL entfernt keine Duplikate, und erfordert nur das schwächste SQL Server Backend-Processing, um die Union-Operation auszuführen.
Vermeiden Sie einen NOLOCK Abfragehinweis
Der NOLOCK Abfragehinweis ist eine der häufigsten T-SQL Best Practices, aber es kann auch einer der schlimmsten sein. Die meisten Entwickler glauben, das Risiko bei der Verwendung eines NOLOCK-Hints bestehe darin, dass die Daten inkonsistent werden. Schließlich liest ein NOLOCK-Hint nur Zeilen und wartet nicht auf andere SQL-Anweisungen wie SELECT und UPDATE. Das ist richtig, aber ein NOLOCK-Hint macht mehr, als nur Zeilen zu lesen.
Transaktionen erledigen schließlich mehr als nur Zeilen auszuwählen, zu aktualisieren und zu löschen. Zum Beispiel erfordern Transaktionen häufig einen Index, der aktualisiert werden muss oder zu wenig Platz auf der Datenseite hat. Dies kann die Zuweisung von neuen Seiten erfordern und die Verlagerung von den Zeilen auf der bestehenden Seite auf diese neue Seite, was als Page Split bezeichnet wird. Aus diesem Grund können Sie mehrere Zeilen auslassen oder Zeilen zweimal in Ihrem Datensatz haben, was in der Regel nicht zulässig ist, wenn Sie Ihre Anfragen ohne NOLOCK Query Hint laufen lassen.
Spaltenlisten für SELECT oder INSERT-Anweisungen bereitstellen
Eine weiterer T-SQL Best Practice Tipp ist es, immer vollständige Spaltenlisten bereitzustellen, die für die SELECT- und INSERT-Anweisung erforderlich sind. Wenn Sie Zum Beispiel SELECT * FROM in Ihrem Code oder in einer Stored Procedure verwenden, wird die Spaltenliste jedes Mal, wenn Sie die SELECT-Anweisung ausführen, aufgelöst. Außerdem generieren SELECT und INSERT-Anweisungen einen Fehler oder geben eine andere Gruppe von Spalten zurück, wenn sich das zugrunde liegende Tabellenschema ändert.
Wenn Sie also etwas selektieren, vermeiden Sie SELECT * FROM [Tablename], und verwenden Sie stattdessen die vollständige Spaltenliste wie folgt:
SELECT [col1], ... [coln] FROM [Tablename].
Analog gilt das bei der Ausführung von Inserts. In diesem Fall sollten Sie in der INSERT-Klausel ebenfalls eine Spaltenliste wie folgt verwenden:
INSERT INTO [Tablename] [col1], [col2] ... [coln])
VALUES ('Wert1, Wert2, ... ValueN)
Fünf weitere T-SQL Best Practices
Nutzen Sie SET NOCOUNT ON: Verwenden Sie SET NOCOUNT ON in Batchfiles, Stored Procedures und bei Triggern, um die Performance zu erhöhen. Der Grund für die Leistungssteigerung liegt daran, dass das Statement die Anzahl der betroffenen Zeilen nicht zurückgibt.
Nutzen Sie besser das EXISTS Keyword statt des IN-Keywords: Wenn Sie die Existenz von Datensätzen überprüfen, sollten Sie das EXISTS Keyword statt des IN-Schlüsselworts verwenden. Das ist deswegen besser, weil IN mit Listen arbeitet und vor der Weiterverarbeitung die kompletten Ergebnisse von Sub-Queries ausgibt. Sub-Queries mit dem Schlüsselwort EXISTS geben hingegen nur entweder TRUE oder FALSE zurück, was schneller ist. Wird nämlich eine Übereinstimmung gefunden, hört es sofort auf, denn die Bedingung hat sich als wahr erwiesen.
Vermeiden Sie Cursor: Vermeiden Sie so weit wie möglich Cursor. Verwenden Sie stattdessen einen set-basierten Ansatz, um Daten zu aktualisieren oder von einer Tabelle in eine andere zu übertragen.
Hände weg von dynamischem SQL: Vermeiden Sie die Verwendung von dynamischem SQL. Versuchen Sie Alternativen zu finden, die dynamisches SQL nicht benötigen. Wenn Sie dynamisches SQL verwenden, nutzen Sie sp_executesql statt EXECUTE (EXEC), weil sp_executesql effizienter und vielseitiger auszuführen ist als EXECUTE. Es unterstützt Parameterersetzung und erzeugt Ausführungspläne, die wahrscheinlich vom SQL Server wiederverwendet werden können.
Verwenden Sie schema-qualifizierte Objektnamen. Siehe Tabellennamen mit Präfixen für Schemanamen. Verwenden Sie beispielsweise SELECT * FROM [Schema].[Tablename] anstelle von SELECT * FROM [Tablename].
Folgen Sie SearchEnterpriseSoftware.de auch auf Facebook, Twitter und Google+!