Zunächst einmal, wenn Sie standardmäßig die InnoDB-Speicher-Engine von MySQL verwenden, gibt es keine Möglichkeit, Daten ohne Zeilensperren zu aktualisieren, außer die Transaktionsisolationsstufe auf READ UNCOMMITTED herunterzusetzen, indem Sie
ausführenSET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
Ich glaube jedoch nicht, dass das Datenbankverhalten Ihren Erwartungen entspricht, da Dirty Read in diesem Fall zulässig ist. READ UNCOMMITTED ist in der Praxis selten sinnvoll.
Um die Antwort von @Tim zu ergänzen, ist es in der Tat eine gute Idee, einen eindeutigen Index für die Spalte zu haben, die in der where-Klausel verwendet wird. Bitte beachten Sie jedoch auch, dass es keine absolute Garantie dafür gibt, dass der Optimierer letztendlich einen solchen Ausführungsplan unter Verwendung des erstellten Indexes auswählt. Es kann je nach Fall funktionieren oder nicht.
In Ihrem Fall könnten Sie die Long-Transaktion in mehrere Short-Transaktionen aufteilen. Anstatt Millionen von Zeilen auf einmal zu aktualisieren, wäre es besser, jedes Mal nur Tausende von Zeilen zu scannen. Die X-Sperren werden freigegeben, wenn jede kurze Transaktion festgeschrieben oder zurückgesetzt wird, was den gleichzeitigen Aktualisierungen die Möglichkeit gibt, fortzufahren.
Übrigens gehe ich davon aus, dass Ihr Stapel eine niedrigere Priorität als die anderen Online-Prozesse hat, sodass er außerhalb der Stoßzeiten geplant werden könnte, um die Auswirkungen weiter zu minimieren.
P.S. Die IX-Sperre befindet sich nicht auf dem Datensatz selbst, sondern ist mit dem Tabellenobjekt mit höherer Granularität verbunden. Und selbst mit der Transaktionsisolationsstufe REPEATABLE READ gibt es keine Lückensperre, wenn die Abfrage einen eindeutigen Index verwendet.
