Po pierwsze, jeśli domyślnie korzystasz z silnika przechowywania InnoDB MySQL, nie ma możliwości aktualizowania danych bez blokad wierszy, z wyjątkiem ustawienia poziomu izolacji transakcji na READ UNCOMMITTED przez uruchomienie
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
Jednak nie sądzę, aby zachowanie bazy danych było tym, czego oczekujesz, ponieważ w tym przypadku dozwolony jest nieczysty odczyt. READ UNCOMMITTED rzadko przydaje się w praktyce.
Aby uzupełnić odpowiedź z @Tim, naprawdę dobrym pomysłem jest posiadanie unikalnego indeksu w kolumnie użytej w klauzuli where. Należy jednak pamiętać, że nie ma absolutnej gwarancji, że optymalizator ostatecznie wybierze taki plan wykonania przy użyciu utworzonego indeksu. Może działać lub nie działać, w zależności od przypadku.
W Twoim przypadku możesz podzielić długą transakcję na wiele krótkich transakcji. Zamiast aktualizować miliony wierszy w jednym ujęciu, lepsze byłoby skanowanie tylko tysięcy wierszy za każdym razem. Blokady X są zwalniane, gdy każda krótka transakcja zostanie zatwierdzona lub wycofana, dając współbieżnym aktualizacjom możliwość kontynuowania.
Przy okazji zakładam, że Twoja partia ma niższy priorytet niż inne procesy online, dlatego może być planowana poza godzinami szczytu, aby jeszcze bardziej zminimalizować wpływ.
PS Blokada IX nie znajduje się w samym rekordzie, ale jest dołączona do obiektu tabeli o wyższej szczegółowości. Nawet przy poziomie izolacji transakcji REPEATABLE READ nie ma luki, gdy zapytanie używa unikalnego indeksu.
