На първо място, ако по подразбиране използвате системата за съхранение на InnoDB на MySQL, тогава няма начин да актуализирате данни без заключвания на редове, освен да настроите нивото на изолация на транзакцията на READ UNCOMMITTED чрез стартиране
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
Не мисля обаче, че поведението на базата данни е това, което очаквате, тъй като мръсното четене е разрешено в този случай. READ UNCOMMITTED рядко е полезен на практика.
За да допълним отговора от @Tim, наистина е добра идея да имате уникален индекс в колоната, използвана в клаузата where. Моля, имайте предвид също, че няма абсолютна гаранция, че оптимизаторът в крайна сметка ще избере такъв план за изпълнение, използвайки създадения индекс. Може да работи или да не работи, в зависимост от случая.
За вашия случай това, което можете да направите, е да разделите дългата транзакция на множество къси транзакции. Вместо да актуализирате милиони редове наведнъж, сканирането само на хиляди редове всеки път би било по-добре. X заключванията се освобождават, когато всяка кратка транзакция се ангажира или върне назад, което дава възможност на едновременните актуализации да продължат.
Между другото, предполагам, че вашият пакет е с по-нисък приоритет от другите онлайн процеси, поради което може да бъде планиран извън пиковите часове, за да се минимизира допълнително въздействието.
P.S. Ключалката IX не е на самия запис, а е прикрепена към обекта на таблицата с по-висока детайлност. И дори при нивото на изолация на транзакциите REPEATABLE READ, няма заключване на пропуск, когато заявката използва уникален индекс.
