SQL Server: NOP Updates allmählich langsamer, warum?

Question

Jede Minute liest dieses Programm eine Reihe von Datensätzen von um DB e repliziert sie in einer anderen DB. In 99% der Fälle besteht es aus einer No Operation, da sich die Daten nicht geändert haben.

Das Problem ist, dass einzelne Überschreibungen langsamer wurden. Mit 2500 Aufzeichnungen wurde es bemerkbar.

Wenn sich die Daten nicht ändern, warum wird SQL langsam langsamer?

Weitere Details: Damals habe ich GUID als Primärschlüssel verwendet (arm mich, ich weiß). Aber soweit ich verstehe, wird die Fragmentierung nur verursacht, wenn neue Einfügungen vorhanden sind oder die Aktualisierungen die Größe der Daten ändern, was in beiden Fällen zu Seitenaufteilungen führt. Meine Theorie ist, dass diese NOP-Updates etwas fragmentieren (nicht leicht zu erkennen) und die Latenz erhöhen. Vielleicht implementiert SQL Server dieses Update als eine Delete/Insert-Transaktion?

Answer 1

Fragmentierung ist nicht der einzige Grund, warum die zufälligen GUIDs die Leistung verlangsamen. Mehr IO ist erforderlich, da Zeilen gleichmäßig in der Tabelle verteilt sind. Dies führt oft zu einer Leistung, die sich mit zunehmender Datenbankgröße allmählich verschlechtert, insbesondere bei herkömmlichen rotierenden Medien. Denken Sie daran, dass Daten zuerst in den Speicher gelesen werden müssen, auch wenn keine Daten aktualisiert werden. Die Wahrscheinlichkeit, dass die Seite mit einer benötigten Zeile bereits im Speicher ist, wird mit rein zufälligen Schlüsselanforderungen reduziert.

Wenn Sie GUIDs verwenden müssen, berücksichtigen Sie einen sequenziellen Wert, der mit NEWSEQUENTIALID oder UuidCreateSequential und einigen Byte-Swapping zugewiesen wurde. In meinem Beitrag Improving Uniqueidentifier Performance finden Sie ein Codebeispiel und weitere Details zu diesem allgemeinen Leistungsproblem.