SQL MAX statt Autowert
Hallo zusammen,
ich habe eine alte Access MDB mit Autowert als Primärschlüssel.
Die will ich nun auf einen SQL Server umziehen und da dann aber nicht mehr mit Autowert (bzw. Autoincrement) arbeiten
sondern selber den PK hochzählen, weil ich den Wert noch für andere Sachen gebrauche.
Jetzt geht aber die performance wahnsinnig in die Knie.
Also eine Tabelle hat sagen wir 2.000.000 Zeilen, früher mit mdb war eine neue Zeile in 1sec. angefügt.
Wenn ich das jetzt mit dem SQL Server mache, hole ich mir ja vorher via "select max(feldid) as maxfeldid from tabelle"
den letzten Wert, addiere 1 drauf und lege dann mit AddNew einen neuen Datensatz an.
Da sind dann schon mal 20-30 sec. drin.
Jetzt meine Frage:
Gibt es etwas performanteres als "select max()" ?
Sollte ich wieder auf Autoincrement gehen ?
Sollte ich über eine Archivlösung nachdenken ? (also von den 2.000.000 Datensätzen werden eigentlich immer nur die letzen 50.000 stark frequentiert, die älteren eher sehr selten)
Schon mal danke für Tipps.
ich habe eine alte Access MDB mit Autowert als Primärschlüssel.
Die will ich nun auf einen SQL Server umziehen und da dann aber nicht mehr mit Autowert (bzw. Autoincrement) arbeiten
sondern selber den PK hochzählen, weil ich den Wert noch für andere Sachen gebrauche.
Jetzt geht aber die performance wahnsinnig in die Knie.
Also eine Tabelle hat sagen wir 2.000.000 Zeilen, früher mit mdb war eine neue Zeile in 1sec. angefügt.
Wenn ich das jetzt mit dem SQL Server mache, hole ich mir ja vorher via "select max(feldid) as maxfeldid from tabelle"
den letzten Wert, addiere 1 drauf und lege dann mit AddNew einen neuen Datensatz an.
Da sind dann schon mal 20-30 sec. drin.
Jetzt meine Frage:
Gibt es etwas performanteres als "select max()" ?
Sollte ich wieder auf Autoincrement gehen ?
Sollte ich über eine Archivlösung nachdenken ? (also von den 2.000.000 Datensätzen werden eigentlich immer nur die letzen 50.000 stark frequentiert, die älteren eher sehr selten)
Schon mal danke für Tipps.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 491082
Url: https://administrator.de/contentid/491082
Ausgedruckt am: 22.11.2024 um 13:11 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
lass den Autoincrement seine arbeit als PrimaryKey tun und kümmere dich mal um Indexe in deiner Tabelle.
Dann werden eine Abfragen auch nicht mehr so lange brauchen.
Solltest du schon einen anderen "AutoIncrementWert" brauchen mach eine eigene Spalte.
lass den Autoincrement seine arbeit als PrimaryKey tun und kümmere dich mal um Indexe in deiner Tabelle.
Dann werden eine Abfragen auch nicht mehr so lange brauchen.
Solltest du schon einen anderen "AutoIncrementWert" brauchen mach eine eigene Spalte.
Hi
und warum verwendest du jetzt nicht den autoincrement?
ggf eine GUID Spalte in betracht ziehen, aber da muss dann schon der Anwendungszweck passen.
Ich tippe hier mangels Informationen aber erst mal darauf, das hier weder entsprechende Indexe gesetzt sind, noch die queries dazu passen.
und warum verwendest du jetzt nicht den autoincrement?
Da sind dann schon mal 20-30 sec. drin.
Dann ist entweder dein Code megaschlecht oder du hast keine/schlechte Indexe gesetzt. oder beidesSollte ich über eine Archivlösung nachdenken ?
Grundsätzlich nie eine schlechte Idee das von Anfang an zu beherzigen. Aber 2Mio Datensätze sind keine Hausnummer für SQL. Das ist ...quasi nichts. Und ein Archiv sauber umzusetzen erfordert idR einiges an Aufwand.Sollte ich wieder auf Autoincrement gehen ?
Für eine IDENTITY Spalte definitiv.ggf eine GUID Spalte in betracht ziehen, aber da muss dann schon der Anwendungszweck passen.
Ich tippe hier mangels Informationen aber erst mal darauf, das hier weder entsprechende Indexe gesetzt sind, noch die queries dazu passen.