Optimierung: Verschieben von Variablendeklarationen an den Anfang Ihrer Prozedur

Während ich an der Optimierung einiger gespeicherter Prozeduren arbeitete, setzte ich mich mit dem DBA zusammen und durchlief einige gespeicherte Prozeduren mit hoher Blockierungs- und / oder hoher Lese- / Schreibaktivität.

Eine Sache, die der DBA erwähnte, war, dass ich alle Variablen (insbesondere TABLEdiejenigen) oben in der gespeicherten Prozedur deklarieren sollte, um ein erneutes Kompilieren zu vermeiden.

Dies ist das erste Mal, dass ich davon gehört habe, und ich habe nach einer Bestätigung gesucht, bevor ich all die verschiedenen gespeicherten Prozeduren, die wir haben, erneut betrachte. Er nannte es "spätes Anzeigen des Codes", und die Neukompilierung sperrte das Schema, das die Blockierung erklären würde.

Reduziert das Verschieben aller Variablendeklarationen an den Anfang Ihrer gespeicherten Prozedur die Neukompilierung?

Nein.

Dies war entweder vor langer Zeit der Fall (und ist es zumindest seit SQL Server 2000 nicht mehr), oder es war nie der Fall, und Ihr DBA hat seine Empfehlung nur mit der folgenden verwechselt :

Es ist wichtig, alle DDL-Anweisungen (wie das Erstellen von Indizes) für temporäre Tabellen zu Beginn einer gespeicherten Prozedur zu gruppieren. Durch Zusammenstellen dieser DDL-Anweisungen können unnötige Kompilierungen aufgrund von Schemaänderungen vermieden werden.

Eine weitere Erläuterung der Gründe für diese Empfehlung finden Sie auf dieser Seite .

Wenn wir uns diese Microsoft-KB ansehen , stellen wir fest, dass die Ursache für eine Neukompilierung einer gespeicherten Prozedur eine der folgenden sein kann (SQL Server 2005+):

1. Schema geändert.
2. Statistik geändert.
3. Kompilieren Sie DNR neu.
4. Set Option geändert.
5. Temp-Tabelle geändert.
6. Remote-Rowset geändert.
7. Für das Durchsuchen der Dauerwellen geändert.
8. Abfragebenachrichtigungsumgebung geändert.
9. MPI-Ansicht geändert.
10. Cursoroptionen geändert.
11. Mit Neukompilierungsoption.

Das Deklarieren einer Variablen - auch einer Tabellenvariablen (dh @table_variable) - kann natürlich keines dieser Ereignisse auslösen, da das Deklarieren einer Variablen nicht als DDL zählt . Eine Variable (auch eine Tabellenvariable) ist ein temporäres Objekt, das ausschließlich für Ihre T-SQL-Programmierung verwendet wird. Deshalb erhalten Tabellenvariablen keine Statistik und sind nicht an Transaktionen gebunden . Das Deklarieren einer Variablen (Tabelle oder nicht) kann keine Neukompilierung des Prozesses auslösen.

Das Erstellen einer temporären Tabelle (dh #temp_tableeines Index) ist jedoch eine DDL, die sich auf die physische Definition der Datenbank auswirkt. Temporäre Tabellen und Indizes sind "echte" Objekte mit Statistiken und Transaktionssteuerung. Wenn Sie diese Objekte erstellen, können Sie eines der Ereignisse 1, 2 oder 5 in der obigen Liste auslösen und so eine Neukompilierung des Prozesses auslösen.

Es sollte keinen Unterschied machen oder die Kompilierungssperren reduzieren oder weniger Neukompilierungen veranlassen, eine Variable auf halber Strecke des Stacks oder ganz oben zu deklarieren. Ich mache das aus Gründen der Lesbarkeit meistens oben.

Um auf den Teil der Frage zu kommen, "Was denkt mein DBA?", Kann ich nur sagen (abgesehen von Nicks Argument, dass sie darüber nachdenken, wie etwas früher war), dass sie vielleicht über Parameter Sniffing (siehe) gesprochen haben Option 2 unter diesem Link ( einfaches Gespräch)

Informationen zu Ihrer Blockierung -> Wenn Sie eine echte Blockierung sehen, ist dies nicht die Art von Kompilierungssperrenkonflikt, über die Ihr DBA am wahrscheinlichsten spricht. Es ist zwar richtig, dass bestimmte Dinge dies beeinflussen (z. B. nicht schemaqualifizierende Tabellen, nicht schemaqualifizierende Aufrufe von gespeicherten Prozeduren), aber dies ist sicherlich nicht die Ursache für Ihre hohen Lesezugriffe und wahrscheinlich auch nicht die Ursache für Ihre Blockierung. Sie sollten auf jeden Fall alles tun, um diese Kompilierungssperren zu umgehen. Ich würde es jedoch als wichtigere Aufgabe ansehen, den Rest des Codes für gespeicherte Prozeduren zu optimieren, als mir Gedanken darüber zu machen, wo sich die Variablen befinden. Lesen Sie auch So identifizieren und beheben Sie Kompilierungssperren, wenn Sie sicherstellen möchten, dass hier keine Probleme auftreten.

Geben Sie diese Vorher / Nachher-Beispiele an und wir werden sehen, was der DBA hier fährt.