Ich bin kein professioneller DBA, aber als Entwickler mit einer B/S-Architektur bin ich immer untrennbar mit der Datenbank verbunden. Im Allgemeinen verwenden Entwickler nur die vier klassischen Anweisungen von SQL: select, insert, delete und update. Aber ich habe nie studiert, wie sie funktionieren. In diesem Artikel möchte ich darüber sprechen, wie Select in der Datenbank funktioniert.
Das klassischste Thema in der B/S-Architektur ist nichts anderes als die dreistufige Architektur, die grob in Datenschicht, Geschäftslogikschicht und Präsentationsschicht unterteilt werden kann mit der Datenbank interagieren, z. B. Datensätze abfragen. Wir schreiben oft die SQL-Abfrage und rufen dann das Programm auf, um die SQL auszuführen. Aber wie sieht der interne Arbeitsablauf aus? Welchen Schritt ich zuerst machen soll, welchen Schritt ich als nächstes machen soll usw. Ich glaube, die meisten meiner Freunde sind sich nicht sicher, genau wie ich.
Schritt 1: Die Anwendung sendet die Abfrage-SQL-Anweisung zur Ausführung an den Server
Wenn wir die SQL-Anweisung im ausführen Auf der Datenschicht stellt die Anwendung eine Verbindung zum entsprechenden Datenbankserver her und sendet die SQL-Anweisung zur Verarbeitung an den Server.
Schritt 2: Der Server analysiert die angeforderte SQL-Anweisung
1. Freunde, die häufig Abfrageanalysatoren verwenden, wissen wahrscheinlich, dass eine Abfrageanweisung zum ersten Mal ausgeführt wird. Die Ausführung dauert sehr lange. Wenn Sie jedoch dieselbe Anweisung sofort oder innerhalb eines bestimmten Zeitraums ausführen, werden die Abfrageergebnisse in kurzer Zeit zurückgegeben.
Grund:
Nach Erhalt der Abfrageanforderung geht der Server nicht sofort zur Abfrage in die Datenbank, sondern sucht im Plan-Cache in der Datenbank nach dem entsprechenden Ausführungsplan existiert, rufen Sie den kompilierten Ausführungsplan direkt auf und sparen Sie so die Kompilierungszeit des Ausführungsplans.
Wenn die abgefragte Zeile bereits im Datenpufferspeicherbereich vorhanden ist, muss die physische Datei nicht abgefragt werden. Stattdessen werden die Daten aus dem Speicher abgerufen schneller sein als das Lesen der Daten von der Festplatte. Es ist viel schneller und verbessert die Abfrageeffizienz. Der Datenpufferspeicherbereich wird später erwähnt.
2. Wenn im SQL-Plan-Cache kein entsprechender Ausführungsplan vorhanden ist, führt der Server zunächst eine Syntaxprüfung für die vom Benutzer angeforderte SQL-Anweisung durch. Wenn ein Syntaxfehler vorliegt, beendet der Server die Abfrage Vorgang ausführen und die entsprechende Fehlermeldung an die Anwendung zurückgeben, die ihn aufruft.
Hinweis: Die zu diesem Zeitpunkt zurückgegebene Fehlermeldung enthält nur grundlegende Syntaxfehlerinformationen, z. B. „select“ wird als „select“ geschrieben usw. Wenn die Fehlermeldung eine Spalte enthält, die nicht in der Liste enthalten ist, wird der Server dies nicht tun Geprüft wird nur die Syntaxüberprüfung, ob die Semantik korrekt ist, bleibt dem nächsten Schritt überlassen.
3. Nachdem die Syntax konsistent ist, beginnen Sie mit der Überprüfung, ob ihre Semantik korrekt ist, z. B. ob die Datenbankobjekte wie Tabellennamen, Spaltennamen, gespeicherte Prozeduren usw. tatsächlich vorhanden sind vorhanden ist, wird beim Beenden der Abfrage ein Fehler an die Anwendung gemeldet.
4. Der nächste Schritt besteht darin, die Analysesperre des Objekts zu erhalten. Wenn wir eine Tabelle abfragen, wird die Einheit der Daten sichergestellt , Es werden Daten eingefügt, aber da keine Sperre vorhanden ist, hat die Abfrage diesen Datensatz bereits gelesen und einige Einfügungen werden aufgrund eines Transaktionsfehlers zurückgesetzt, was zu einem Dirty-Read-Phänomen führt.
5. Der nächste Schritt besteht darin, die SQL-Anweisungssyntax und -semantik zu überprüfen. Wenn der Datenbankbenutzer nicht über die entsprechenden Zugriffsberechtigungen verfügt. Der Server meldet den Anwendungen nicht genügend Berechtigungen. In größeren Projekten enthält ein Projekt häufig unterschiedliche Berechtigungen, einige haben nur Leseberechtigungen, andere nur Schreibberechtigungen kann lesen und schreiben. Wenn Sie nicht aufpassen, ist Ihre SQL-Anweisung nutzlos, wenn sie perfekt ist.
6. Der letzte Schritt der Analyse besteht darin, den endgültigen Ausführungsplan festzulegen. Wenn Syntax, Semantik und Berechtigungen überprüft wurden, sendet der Server die Ergebnisse nicht sofort an Sie zurück. Stattdessen optimiert er Ihr SQL und wählt verschiedene Abfragealgorithmen aus, um es in der effizientesten Form an die Anwendung zurückzugeben. Wenn beispielsweise Tabellen-Join-Abfragen durchgeführt werden, entscheidet sich der Server letztendlich für die Verwendung von Hashjoin, Mergejoin oder Loopjoin, basierend auf den Kosten, welcher Index effizienter ist usw. Die automatische Optimierung ist jedoch begrenzt, um effiziente Abfragen zu schreiben SQL muss seine eigenen SQL-Abfrageanweisungen noch optimieren.
Nachdem der Ausführungsplan ermittelt wurde, wird der Ausführungsplan beim nächsten Mal, wenn dieselbe Ausführungsanforderung vorliegt, direkt aus dem Plancache abgerufen, um eine Neukompilierung des Ausführungsplans zu vermeiden.
Schritt 3: Anweisungsausführung
Nachdem der Server das Parsen der SQL-Anweisung abgeschlossen hat, weiß der Server, was die Anweisung bedeutet, und führt die SQL-Anweisung dann tatsächlich aus.
Zu diesem Zeitpunkt gibt es zwei Situationen:
Wenn die in der Abfrageanweisung enthaltenen Datenzeilen in den Datenpufferspeicherbereich gelesen wurden, liest der Server die Daten direkt aus dem Datenpuffer Speicherbereich und geben Sie es an Anwendungen zurück. Vermeiden Sie das Lesen aus physischen Dateien und verbessern Sie die Abfragegeschwindigkeit.
Wenn sich die Datenzeile nicht im Datenpuffer befindet, wird der Datensatz aus der physischen Datei gelesen und an die Anwendung zurückgegeben, und die Datenzeile wird zur nächsten Verwendung in den Datenpuffer geschrieben.
Hinweis: Es gibt mehrere Arten von SQL-Cache. Aufgrund der Existenz des Caches ist es für uns manchmal schwierig, die Ergebnisse der Optimierung sofort zu sehen Die Ausführung ist sehr schnell, daher ist es im Allgemeinen erforderlich, zuerst den Cache zu entfernen und dann die Leistung vor und nach der Optimierung zu vergleichen:
DBCCDROPCLEANBUFFERS
Alles aus dem Pufferpool löschen. Löschen Sie den Puffer.
DBCCFREEPROCCACHE
Entfernt alle Elemente aus dem Prozedurcache.
DBCCFREESYSTEMCACHE
Alle nicht verwendeten Cache-Einträge aus allen Caches freigeben. Die SQLServer2005-Datenbank-Engine bereinigt zuvor nicht verwendete Cache-Einträge im Hintergrund, um Speicher für aktuelle Einträge verfügbar zu machen. Sie können diesen Befehl jedoch verwenden, um nicht verwendete Einträge manuell aus allen Caches zu entfernen.
Dies kann die Auswirkungen des SQL-Cache nur grundsätzlich beseitigen. Es scheint keine Lösung zu geben, um den Cache vollständig zu entfernen. Bitte geben Sie mir einen Rat.
Schlussfolgerung: Nur wenn wir den Operationsprozess des von der Dienstausführungsanwendung übermittelten SQL kennen, können wir unsere Anwendung gut debuggen.
Stellen Sie sicher, dass die SQL-Syntax korrekt ist;
Stellen Sie sicher, dass die SQL-Semantik korrekt ist, d. h., ob das Objekt vorhanden ist;
Ob der Datenbankbenutzer über den entsprechenden Zugriff verfügt Rechte.
