SQL Server IDENTITY-Spalteninkrementlücken: Den Cache verstehen
Die IDENTITY
-Spalte von SQL Server, die zum Generieren eindeutiger Zeilenbezeichner verwendet wird, zeigt manchmal unerwartetes Verhalten: Nach einem Serverneustart springt das Inkrement um Hunderte, anstatt sich sequenziell um eins zu erhöhen. Dies ist kein Fehler, sondern eine Folge der in SQL Server 2012 eingeführten Leistungsoptimierungen.
SQL Server speichert Identitätswerte zwischen, um die Leistung zu steigern. Dieser Cache speichert normalerweise 1.000 int
-Werte oder 10.000 bigint
/numeric
-Werte. Sobald der Cache aufgebraucht ist, wird ein neuer Stapel zugewiesen. Beim Neustart des Servers werden jedoch alle nicht verwendeten zwischengespeicherten Werte verworfen.
Der beobachtete Sprung, bei dem die letzten drei Ziffern konstant bleiben (z. B. immer mit 306 enden), spiegelt die verbleibenden Cache-Werte nach der anfänglichen Zuweisung von 1.000 wider.
Während dieser Caching-Mechanismus Lücken in der IDENTITY
-Sequenz schafft, verbessert er in erster Linie die Leistung. Sofern keine häufigen Neustarts üblich sind, sind die Auswirkungen minimal. Es gibt jedoch mehrere Möglichkeiten, dies zu mildern:
IDENTITY
-Spalten durch SEQUENCE
-Objekte, um eine genauere Kontrolle über die Cache-Größe zu ermöglichen.ALTER DATABASE SCOPED CONFIGURATION SET IDENTITY_CACHE = OFF;
aus, um das Caching für eine bestimmte Datenbank zu deaktivieren.Es ist wichtig zu bedenken, dass selbst mit diesen Problemumgehungen gleichzeitige Einfügungen und Transaktions-Rollbacks immer noch Lücken verursachen können. Für Anwendungen, die absolute Sequenzkontinuität erfordern, sollten Sie Alternativen wie UUID-Generatoren oder benutzerdefinierte Sequenzimplementierungen in Betracht ziehen.
Das obige ist der detaillierte Inhalt vonWarum springen meine SQL Server-IDENTITY-Inkremente nach einem Neustart?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!