Блокирует ли MySQL InnoDB несколько строк с уровнем изоляции READ_COMMITTED?

У меня проблемы с устранением ошибки LOCK WAIT TIMEOUT EXCEED в MySQL InnoDB.

Я прошел через эта статья, и в ней говорится, что если мы используем уровень изоляции READ_COMMITTED, то мой запрос на обновление должен блокировать только те строки, которые соответствуют условию WHERE, но это не работает для меня, поскольку я получаю блокировки 54 строк для этого запроса .

Результат SHOW ENGINE INNODB STATUS; приведен ниже.

---TRANSACTION 8AE162608, ACTIVE 102 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 56 lock struct(s), heap size 6960, 54 row lock(s), undo log entries 135
MySQL thread id 18013536, query id 164766412915 localhost MyDataDb Updating
update stock set quantity = quantity + -1, last_updated_dts='2015-01-19 00:08:23', last_updated_by='vishal' where location = 1 and product_id = '123'
------- TRX HAS BEEN WAITING 98 SEC FOR THIS LOCK TO BE GRANTED:

Почему у меня блокируются 54 строки, в то время как условие моего запроса на обновление соответствует только одной строке, и я использую уровень изоляции READ_COMMITED?


person Vishal Zanzrukia    schedule 22.05.2015    source источник


Ответы (1)


У уровня изоляции транзакций READ_COMMITTED есть обещание: база данных обещает читать только зафиксированные данные и не допускать еще не зафиксированных данных в транзакцию.

Ошибка тайм-аута блокировки является ошибкой времени выполнения: база данных пытается обновить данные, но не может найти подходящий момент для этого (см. innodb_lock_wait_timeout упомянутый здесь в справочном руководстве по MySQL). Даже если данных для модификации нет, базе данных нужно найти момент времени, чтобы заявить об этом.

Уровень изоляции транзакций READ_COMMITTED уже повышает шансы базы данных найти подходящий момент для обновления данных (см. здесь, например), но он не может предотвратить блокировку всей таблицы другими запросами/транзакциями (полное сканирование таблицы, как, вероятно, делает ваш запрос-виновник).

Еще несколько поисков показывают возможное решение вашей проблемы с удалением.

person Bud Damyanov    schedule 22.05.2015