Прежде всего, если вы по умолчанию используете механизм хранения InnoDB MySQL, вы не сможете обновлять данные без блокировок строк, за исключением установки уровня изоляции транзакции на READ UNCOMMITTED, запустив
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
Однако я не думаю, что поведение базы данных является тем, чего вы ожидаете, поскольку в этом случае разрешено грязное чтение. READ UNCOMMITTED редко бывает полезным на практике.
Чтобы дополнить ответ от @Tim, действительно неплохо иметь уникальный индекс для столбца, используемого в предложении where. Однако обратите внимание, что нет абсолютной гарантии, что оптимизатор в конечном итоге выберет такой план выполнения, используя созданный индекс. Это может работать или не работать, в зависимости от случая.
В вашем случае вы могли бы разделить длинную транзакцию на несколько коротких транзакций. Вместо того, чтобы обновлять миллионы строк за один снимок, было бы лучше сканировать каждый раз только тысячи строк. Блокировки X снимаются, когда каждая короткая транзакция фиксируется или откатывается, давая возможность одновременным обновлениям продолжить.
Кстати, я предполагаю, что ваша партия имеет более низкий приоритет, чем другие онлайн-процессы, поэтому ее можно запланировать в нерабочее время, чтобы еще больше минимизировать влияние.
P.S. Блокировка IX находится не в самой записи, а прикреплена к объекту таблицы с более высокой степенью детализации. И даже с уровнем изоляции транзакции REPEATABLE READ блокировка пропусков отсутствует, когда запрос использует уникальный индекс.
person
flyingice
schedule
19.04.2019