UPDATE-oder MERGE-von sehr großen Tabellen in SQL Server
Ich ausführen muss, um einen täglichen update von einer sehr großen (300 Datensätze) und breiten TABLE1
. Die Quelle der Daten für die updates befindet sich in einer anderen Tabelle UTABLE
10%-25% der Zeilen von TABLE1
aber ist eng. Beide Tabellen haben record_id
als Primärschlüssel.
Derzeit, ich bin Neuerstellung TABLE1
mit dem folgenden Ansatz:
<!-- language: sql -->
1) SELECT (required columns) INTO TMP_TABLE1
FROM TABLE1 T join UTABLE U on T.record_id=U.record_id
2) DROP TABLE TABLE1
3) sp_rename 'TMP_TABLE1', 'TABLE1'
Aber das dauert fast 40 Minuten auf meinem server (60GB RAM für SQL Server). Ich möchte erreichen, die eine 50% performance-Gewinn, - welche anderen Möglichkeiten kann ich ausprobieren?
-
MERGE
undUPDATE
- so etwas wie der code unten funktioniert schneller, nur für einen sehr kleinenUTABLE
Tabelle in voller Größe, alles hängt nur:<!-- language: SQL --> MERGE TABLE1 as target USING UTABLE as source ON target.record_id = source.record_id WHEN MATCHED THEN UPDATE SET Target.columns=source.columns
-
Hörte ich, dass ich einen batch ausführen SERIENDRUCK mithilfe ROWCOUNT - aber ich glaube nicht, dass es sein kann, schnell genug für einen 300M Zeile der Tabelle.
-
Jede SQL-Abfrage-Tipps, die hilfreich sein können?
- Kannst du die Abfrage-plan?
- Hi @chris, query plan ist genial einfach: 1 Scannen der Tabelle "TABELLE1", 2 Table Scan UTABLE, 3 - HASH-JOIN, 4 ZUSAMMENFÜHREN. Ersten und Letzten Schritt nehmen 90% der Zeit. Aber ich habe schon verstanden, wie meine Frage - siehe meine eigene Antwort.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Tatsächlich habe ich herausgefunden, Allgemeine Empfehlungen für solche Abfragen: Idee verwenden von SQL-Merge oder Update ist eine sehr clevere, aber es schlägt fehl, wenn wir aktualisieren müssen viele Datensätze (d.h. 75M) in einer großen und breiten Tisch (d.h. 240M).
Blick auf den Abfrageplan für die folgende Abfrage können wir sagen, dass
TABLE SCAN
von TABELLE1 und LetzteMERGE
nehmen 90% der Zeit.So, in Reihenfolge zu verwenden, ZUSAMMENFÜHREN, müssen wir:
UTABLE
kleinere oder die Angabe zusätzlichercondition
verengt, dass Teil zu-sein-verschmolzen.TABLE1
zweimal weniger reduziert meine eigentliche query-Zeit von 11 Stunden 40 Minuten.Als Mark erwähnt, können mit
UPDATE
syntax und die VerwendungWHERE
Klausel zu engen Teil zu-sein-verschmolzen - so erhalten die gleichen Ergebnisse. Auch vermeiden Sie bitte die IndizierungTABLE1
da dadurch zusätzliche Arbeit zu rebuild index währendMERGE
Erstes würde ich herausfinden, wo dein Flaschenhals ist deine CPU-gebunden oder im Leerlauf? In anderen Worten - ist Ihren IO-subsystem kann mit der Belastung umgehen, richtig?
Wiederherstellung der vollen Tisch ist viel IO-Last, nicht zu erwähnen, es dauert bis eine Menge Platz, um im Grunde, dass die Tabelle zweimal gespeichert vorübergehend.
Tun, die Sie durchführen müssen, eine ZUSAMMENFÜHRUNG von dem, was ich sehen kann, ein einfaches update sollte ausreichen. Beispiel:
Könnte man batch bis die updates mit ROWCOUNT, aber das wird nicht beschleunigen die Ausführung, es wird nur helfen, mit Verringerung der Gesamt-Verriegelung.
Auch - welche Art von Indizes haben Sie sich auf dem Tisch? Kann es schneller sein, die Indizes deaktivieren, bevor das update und dann neu erstellen Sie von Grund auf danach (nur die nicht gruppierten).