Warum verursachen fensterbasierte Aggregatfunktionen so viele logische Lesevorgänge in SQL Server?

Warum die hohen logischen Lesevorgänge für Fensteraggregatfunktionen?

Bei der Verwendung gängiger Unterausdruckspools in Ausführungsplänen sind die logischen Lesevorgänge tendenziell erheblich überhöht für größere Tische. Nach dem Experimentieren und Beobachten des Ausführungsplans wurde festgestellt, dass die folgende Formel zuzutreffen scheint:

Logische Lesevorgänge der Arbeitstabelle = 1 NumberOfRows 2 NumberOfGroups 4

Der zugrunde liegende Grund für diese Formel bleibt jedoch unklar. Ziel dieses Artikels ist es, das Geheimnis hinter dieser logischen Leseberechnung zu lüften.

Grundlegendes zur Ausführung von Aggregatfunktionen mit Fenstern

Der Segmentiterator am Anfang des Plans hängt eine Markierung an Zeilen an Zeigt den Beginn jeder neuen Partition an. Anschließend ruft der primäre Segmentspool die Zeilen einzeln ab und fügt sie in eine tempdb-Arbeitstabelle ein. Beim Erkennen des neuen Gruppenflags gibt die Spule eine Zeile an den oberen Eingang des Operators für verschachtelte Schleifen zurück.

Dies löst die Stream-Aggregation über die Arbeitstabellenzeilen aus und berechnet den Durchschnitt. Der berechnete Durchschnitt wird dann mit den Arbeitstabellenzeilen verknüpft und die Arbeitstabelle wird zur Vorbereitung auf die nächste Gruppe abgeschnitten. Die Segmentspule generiert eine Dummy-Zeile, um die endgültige Gruppe zu verarbeiten.

Logische Leseberechnung für Arbeitstabellen

Nach unserem Verständnis ist die Arbeitstabelle ein Heap (oder Indexspule). sofern im Plan nicht anders angegeben). Im bereitgestellten Beispiel sind wider Erwarten nur 11 logische Lesevorgänge erforderlich. Eine Erklärung für diesen Unterschied lautet wie folgt:

• Zeileneinfügungen in die Arbeitstabelle machen jeweils einen logischen Lesevorgang aus, was zu 3 logischen Lesevorgängen führt.
• Die Berechnung des Durchschnitts erfordert einen logischen Lesevorgang. Dies ergibt insgesamt 4 Lesevorgänge.
• Das Zurückgeben von Zeilen mit der Durchschnittsspalte erfordert vier logische Schritte Lesevorgänge.
• Das Abschneiden der Arbeitstabelle führt zu keinen logischen Lesevorgängen.

Dadurch beträgt die Gesamtzahl der logischen Lesevorgänge 4 x 3 = 12, wobei das Einfügen der vierten Zeile, die einen logischen Lesevorgang auslöst, entfällt nur im Original Szenario.

Fazit

Der Schlüssel zum Verständnis dieser Formel liegt in der Diskrepanz zwischen der logischen Lesezählung für Arbeitstabellen und reguläre Spooltabellen. Bei Arbeitstabellen wird jede gelesene Zeile als ein logischer Lesevorgang gezählt, während bei Spooltabellen jede gehashte Seite gezählt wird.

Die Formel stimmt mit der beobachteten Ausführung überein: Zwei sekundäre Spools werden zweimal gelesen (2 COUNT ()), während die primäre Spule (COUNT(DISTINCT CustomerID) 1) Zeilen ausgibt, wie im erwähnten Blogeintrag erläutert zusätzliche Informationen. Die zusätzliche Zeile ist auf die zusätzliche Zeile zurückzuführen, die ausgegeben wird, um das Ende der letzten Gruppe anzuzeigen.

Das obige ist der detaillierte Inhalt vonWarum verursachen fensterbasierte Aggregatfunktionen so viele logische Lesevorgänge in SQL Server?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!