ВЫБЕРИТЕ ОБНОВЛЕНИЕ для заблокированных запросов

Question

Я использую MySql 5.x, и в моей среде у меня есть таблица с именем CALLS.

Таблица CALLS имеет статус столбца, который принимает перечисление {inprogress, complete}.

Я хочу, чтобы чтение / обновление таблицы было заблокировано строкой, поэтому:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET AUTOCOMMIT = 0;
SELECT amount from CALLS where callId=1213 FOR UPDATE;
COMMIT

По сути, я делаю ОБНОВЛЕНИЕ даже в ситуациях, когда мне нужно только прочитать сумму и вернуть. Я считаю, что это позволяет мне гарантировать, что чтение / обновления не мешают друг другу. Однако мне сказали, что это уменьшит параллелизм приложения.

В любом случае можно ли добиться такой же согласованности транзакций без накладных расходов на блокировку? Благодаря.

Answer 1

Отказ от ответственности: MySQL, как правило, полон сюрпризов, поэтому следующее может быть неверным.

То, что вы делаете, не имеет для меня никакого смысла: вы делаете коммит после SELECT, что должно сломать блокировку. Так что, по моему мнению, ваш код не должен вызывать значительных накладных расходов; но это также не даст вам улучшения согласованности.

В общем, SELECT FOR UPDATE может быть очень разумным и разумным способом обеспечения согласованности, не принимая больше блокировок, чем действительно необходимо. Но, конечно, его следует использовать только при необходимости. Возможно, у вас должны быть разные пути кода: один (использующий FOR UPDATE), используемый, когда полученное значение используется в последующей операции изменения. И еще один (без использования FOR UPDATE), используемый, когда значение не нужно защищать от изменений.

Answer 2

То, что вы реализовали там - если вы не были знакомы с ним - называется пессимистическая блокировка . Вы жертвуете производительностью ради согласованности, что иногда является правильным выбором. В своем профессиональном опыте я обнаружил, что пессимистическая блокировка - это скорее препятствие, чем помощь.

С одной стороны, это может привести к тупику .

(лучше imho) альтернатива - оптимистическая блокировка , в которой вы предполагаете, что столкновения происходят нечасто, и вы просто имеете дело с ними, когда они случаются. Вы делаете свою транзакцию в транзакции, поэтому коллизия не должна оставлять ваши данные в несогласованном состоянии.

Вот дополнительная информация о оптимистической блокировке в смысле Java, но идеи применимы ко всему.