Warum muss bei dem Vorhandensein von allen Datensätzen die ID berechnet werden? Der neueste Satz kommt immer in den ältesten Satz.
Ungefähr sowas:
SQL-Code:
UPDATE LogTable
SET
Column1 = 'NeuerWert1',
Column2 = 'NeuerWert2',
LogTime = '2025-07-19 20:00:00'
WHERE LogTime = (
SELECT MIN(LogTime) FROM LogTable
)
Ist die ID dann überhaupt noch erforderlich?
Brauchst Du zwingend eine ID und hast zwingend jede Sekunde einen Satz, dann könnte die ID auch ein UnixTimeStamp sein (Sekunden seit 1.1.1970), das geht dann bis zum dem 19. Januar 2038, 03:14:07 UTC gut. Bei BIGINT hättest Du noch etwa 584 Milliarden Jahren Zeit, bis ein Überlaufproblem auftritt.
Bei den Lücken setzt Du nur die ID auf den UnixTimeStamp, um die Reihenfolge beibehalten zu können, die LogTime aber auf Null. Damit kannst Du dann die Sortierung der Datensätze beibehalten und trotzdem die Lücken erkennen. (Auch, wenn es sich strenggenommen bei der ID als UnixTimeStamp und LogTime als DateTime um eine Redundanz handelt, könnte das hier sinnvoll und/oder praktikabel sein.)
Das Update müsste dann aber abgeändert werden:
SQL-Code:
UPDATE LogTable
SET
Column1 = 'NeuerWert1',
Column2 = 'NeuerWert2',
LogTime = '2025-07-19 20:00:00'
ID = UnixTimeStampVonLogTime
WHERE ID = (
SELECT MIN(ID) FROM LogTable
)
Um den Index nicht zu sehr anwachsen zu lassen kannst Du per
SQL-Code:
SELECT
index_type_desc,
avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats (DB_ID(), OBJECT_ID('LogTabelle'), NULL, NULL, 'LIMITED')
WHERE avg_fragmentation_in_percent > 10
prüfen, ob er fragmentiert ist, wenn ja, rufst Du ein
ALTER INDEX IX_Timestamp ON LogTabelle REORGANIZE;
auf. Welcher Wert hier für avg_fragmentation_in_percent >
10 sinnvoll ist, müsstest Du ggfls. ausprobieren. Ein Index auf die ID dürfte dann ausreichen, ein zweiter Index auf LogTime wäre dann nicht erforderlich, da ja beide Spalten den gleichen Wert repräsentieren.
Ist jetzt nur so 'ne Idee, ob's umsetzbar ist, weiß ich nicht bzw. kann ich nicht beurteilen, da ich den genauen Aufbau des Systems nicht kenne.