DELETE-Befehl ist zu langsam in eine Tabelle mit einem Gruppierten Index

Ich habe eine ziemlich große Tabelle mit dem Namen FTPLog mit rund 3 Millionen aufnehmen wollte ich hinzufügen, ein löschen-Mechanismus, um löschen Sie alte Protokolle, aber Befehl löschen dauert lange. Ich fand, dass gruppierten index löschen dauert lange.

DECLARE @MaxFTPLogId as bigint
SELECT @MaxFTPLogId = Max(FTPLogId) FROM FTPLog WHERE LogTime <= DATEADD(day, -10 , GETDATE())
PRINT @MaxFTPLogId
DELETE FROM FTPLog WHERE FTPLogId <= @MaxFTPLogId

Möchte ich wissen, wie kann ich die Leistung verbessern zu löschen?

Ist die FTPLogID Spalte indiziert?
Ja, es ist primary key
Wie viele Zeilen gelöscht werden, und wie lange dauert es?
Gibt es noch andere Indizes auf der Tabelle außer dem Primärschlüssel?
Es gibt keine andere Indizes habe ich herausgefunden, dass zuerst löschen, ist sehr zeitaufwändig.Es ist über 2 Millionen Datensätze

InformationsquelleAutor Ahmadreza | 2009-05-27

  1. 14

    Könnte es langsam sein, weil ein großer löschen, erzeugt ein großes Transaktionsprotokoll. Versuchen Sie, löschen Sie es in Stücke, wie:

    WHILE 1 = 1
BEGIN
    DELETE TOP (256) FROM FTPLog WHERE FTPLogId <= @MaxFTPLogId
    IF @@ROWCOUNT = 0
        BREAK
END

    Dies erzeugt kleinere Transaktionen. Und es mildert locking Probleme durch die Schaffung von Raum zum atmen für andere Prozesse.

    Könnten Sie auch einen Blick in partitionierte Tabellen. Diese potentiell erlauben, Sie zu reinigen, die alten Einträge durch löschen einer ganzen partition.

    Ich habe immer das bei der Durchführung große löscht aus Tabellen, wo ich will, um zu vermeiden, sperren Sie Sie. Ausgezeichnete Empfehlung.
    Immer verwenden Sie immer die Chargen beim löschen eine Menge von Daten. IMMER.

    InformationsquelleAutor Andomar

  2. 7

    Da es eine log-Tabelle, gibt es keine Notwendigkeit, die gruppiert ist.

    Ist es unwahrscheinlich, dass Sie suchen, werden Sie auf Id.

    Ändern Sie Ihre PRIMARY KEY so, dass es unclustered. Dies wird mit HEAP Lagerung-Methode, die schneller auf die DML:

    ALTER TABLE FTPLog DROP CONSTRAINT Primary_Key_Name
ALTER TABLE FTPLog ADD CONSTRAINT Primary_Key_Name PRIMARY KEY NONCLUSTERED (FTPLogId)

    und nur Problem:

    SELECT @MaxFTPLogTime = DATEADD(day, -10 , GETDATE())
PRINT @MaxFTPLogId
DELETE FROM FTPLog WHERE LogTime <= @MaxFTPLogTime

    InformationsquelleAutor Quassnoi

  3. 1

    Überprüfen Sie die Dichte der Tabelle (verwenden Sie den Befehl DBCC showcontig zu überprüfen, Dichte)
    Scan-Dichte [Bester Wert:Tatsächlicher Wert] sollte dieser parameter näher an 100% und Logische scanfragmentierung parameter werden sollte, näher zu 0% für die beste Leistung von Ihrem Tisch. Wenn nicht, re-index und refragment der index der Tabelle zu verbessern die performance Ihrer Ausführung der Abfrage.

    InformationsquelleAutor Samiksha

  4. 0

    Ich gehe davon aus, dass nicht nur diese Tabelle ist riesig in Bezug auf die Anzahl der Zeilen, sondern auch, dass es wirklich schwer für die Anmeldung neue Einträge, während Sie versuchen, es zu bereinigen.

    Vorschlag von Andomar sollte helfen, aber ich würde versuchen, es zu bereinigen, auch wenn es keine Einsätze geht.

    Alternative:, wenn Sie schreiben Protokolle, die Sie wahrscheinlich interessieren sich nicht die Transaktions isolation die so viel. Ich würde es daher ändern Sie die Isolationsstufe für die code/- Prozesse, das schreiben der log-Einträge, so dass Sie kann vermeiden Sie das erstellen von riesigen tempdb (by the way, überprüfen Sie, ob tempdb-Datenbank wächst, eine Menge während dieser Löschvorgang)

    Außerdem denke ich, dass Löschungen aus dem clustered index sollte nicht wirklich langsamer als die von nicht-gruppierten eins: Sie sind immer noch psysically löschen von Zeilen. Der Wiederaufbau dieses index danach kann einige Zeit dauern, aber.

    Scheinbar ly ist es nicht, weil der gruppierte index, weil ich habe versucht die Lösung von Quassnoi und es hat nicht funktioniert.

    InformationsquelleAutor van

Schreibe einen Kommentar