0
Kann man erklären, ob dies ein gutes Beispiel für eine tote Sperre für SQL Stored Procedure ist?SQL DeadLock Beispiel
BEGIN TRANSACTION MergeAccount
MERGE INTO Name AS TARGET
USING (
SELECT @accountId, @playerName, @lastSeenDateTime
) AS SOURCE (
[AccountId], [Name], [LastSeenDateTime]
)
ON TARGET.[AccountId] = SOURCE.[AccountId]
AND
(
SELECT TOP 1 [Name]
FROM [Name]
WHERE [AccountId] = @AccountId
ORDER BY [LastSeenDateTime] DESC
) = SOURCE.[Name]
WHEN NOT MATCHED BY TARGET THEN
INSERT (
[AccountId], [Name], [LastSeenDateTime]
) VALUES (
[AccountId], [Name], [LastSeenDateTime]
)
WHEN MATCHED AND SOURCE.LastSeenDateTime > TARGET.LastSeenDateTime THEN
UPDATE
SET TARGET.LastSeenDateTime = SOURCE.LastSeenDateTime
;
COMMIT TRANSACTION MergeAccount
Zum Beispiel, wenn Sie die SELECT-Anweisung in der WHERE-Klausel überprüfen, bitte ich eigentlich für Daten in der gleichen Tabelle des gleichen Benutzers.
Sollte ich eine DECLARE erstellen und die Daten in eine Variable außerhalb übernehmen, dann wenden Sie die WHERE-Klausel an?
Ist es eine schlechte Übung, eine Abfrage als solche zu schreiben?
Deadlocks passieren zwischen * verschiedenen * Sitzungen, nicht in einer Anweisung einer Sitzung. (Mit Ausnahme der seltenen, seltenen Intra-Statement Deadlocks mit Parallelität; diese werden als Bugs betrachtet. "MERGE" hat tatsächlich ein paar solcher Bugs gesehen.) Haben Sie tatsächlich Deadlocks, die Sie zu lösen versuchen, oder ist das ein hypothetisches Problem? –
Hier ist ein ähnliches Szenario mit einer guten Erklärung: https://dba.stackexchange.com/questions/23467/merge-statement-deadlocking-self. Per @ JeroenMostert obwohl; Dies erfordert eine konkurrierende zweite Sitzung. – JohnLBevan
@JeroenMostert Dies ist ein gültiges Anliegen, da ich Probleme habe. Das Programm meldet dies in dieser Stored Procedure. Obwohl es sehr einfach ist, gibt es Konkurrenz mit anderen Sitzungen (wir laufen viele Bots der gleichen Anwendung). Nicht einmal sicher, wie man es vereinfacht, da es schon ziemlich einfach ist. –