SQL Server-Deadlock-Fix: Force join-Reihenfolge, oder automatisch wiederholen?

ich habe eine gespeicherte Prozedur, führt eine Verknüpfung der TableB zu TableA:

 SELECT <--- Nested <--- TableA
             Loop   <--
                      |
                      ---TableB

Zur gleichen Zeit, in einer Transaktion, Zeilen eingefügt werden TableA, und dann in TableB.

Diese situation ist gelegentlich verursachen deadlocks, wie die gespeicherte Prozedur wählen Sie packt Zeilen aus TableB, während die insert fügt Zeilen zu TableA, und jeder will den anderen gehen zu lassen die andere Tabelle:

INSERT     SELECT
=========  ========
Lock A     Lock B
Insert A   Select B
Want B     Want A
....deadlock...

Logik erfordert die INSERT ersten Zeilen hinzufügen Eine, und dann zu B, während ich persönlich kümmern sich nicht die Reihenfolge, in der SQL Server führt die join - solange es kommt.

Der gemeinsamen Empfehlung für die Behebung von deadlocks ist, um zu gewährleisten, dass jeder Zugriff auf Ressourcen in der gleichen Reihenfolge. Aber in diesem Fall SQL Server-Optimierer ist mir, dass die umgekehrte Reihenfolge ist "besser". ich kann anderen Kraft join-Reihenfolge, und haben eine schlechtere ausführen der Abfrage.

Aber sollte ich?

Soll ich überschreiben der Optimierer, jetzt und für immer, mit einer join-Reihenfolge, die ich möchte es zu benutzen?

Oder sollte ich einfach trap Fehler systemeigene Fehler 1205, und erneut die select-Anweisung?

Die Frage ist nicht, wie viel schlimmer die Abfrage durchführen kann, wenn ich das überschreiben der optimizer und für es zu tun, etwas, was nicht optimal ist. Die Frage ist: ist es besser, sich automatisch wiederholen, anstatt schlimmer Abfragen?

InformationsquelleAutor Ian Boyd | 2010-03-04
Schreibe einen Kommentar