Все о MySQL. Выбор соответствующего уровня изолированности

Переход с уровня изолированности READ UNCOMMITTED на более безопасный уровень SERIALIZABLE также влияет на производительность реляционной СУБД. Причина этого довольно проста: чем большей целостности данных вы хотите добиться от системы, тем в большем объеме она должна выполнять обработку и, соответственно, тем медленнее она будет работать. Поэтому администратору базы данных или системному аналитику приходится лавировать между требованиями изолированности реляционной СУБД и требованиями ее производительности.
На уровне изолированности SERIALIZABLE СУБД выполняет транзакции последо­вательно и поэтому обеспечивает наивысший уровень защиты от разрушения данных. Однако из-за увеличения периодов ожидания снятия блокировок другими транзакциями, это может существенно снизить скорость работы вашего приложения. Что же касается уровня изолированности READ UNCOMMITTED, то он позволяет "просматривать" па­раллельным транзакциям несохраненные изменения, произведенные другими тран­закциями, и обеспечивает более высокую производительность, но одновременно спо­собствует повышению риска получения нецелостных данных. На рис. 12.8 проиллюст­рирована обратная зависимость между безопасностью транзакции и производитель­ностью системы.
По умолчанию MySQL устанавливает уровень изолированности REPEATABLE READ. Этот уровень изолированности подходит для большинства приложений, и его можно ме­нять только тогда, когда для приложения требуется, чтобы оно обеспечивало более высо­кий или более низкий уровень изолированности. Общей рекомендации относительно того, какой уровень изолированности является правильным, не существует. Обычно решение принимается на основе того, насколько приложение будет чувствительным к ошибкам, и на основе оценки разработчика приложения о влиянии потенциально некорректных данных. Выбор уровня изолированности не обязательно будет один и тот же даже в пределах одного приложения. Вполне вероятно, например, что для различных транзакций, входящих в одно и то же приложение, могут потребоваться совершенно разные уровни изолированности. Такое решение принимается с учетом тех задач, которые решает приложение.

Избегайте взаимоблокировок
Описание работы транзакций нельзя считать законченным без краткого описания взаимоблокировок. Если вы знакомы с программированием операционных систем, вы наверняка уже знаете, что взаимоблокировка - это ситуация, когда два процесса блоки­руют друг друга при осуществлении доступа к одному и тому же ресурсу, причем каждый из них ожидает момента завершения другого процесса. 
В контексте транзакций взаимоблокировка происходит тогда, когда два и более клиента одновременно пытаются обновить одни и те же данные, но в разной последовательности. Рассмотрим рис. 12.9, на котором показано, как две транзакции работают с одним и тем же набором таблиц, но в различной последовательности.
Первая транзакция делает попытку снять 400 акций со счета, в то время как вторая пытается добавить 1000 акций. Обе транзакции запущены одновременно, но сначала первая транзакция (действие 1) уменьшает счет на 400 акций, а затем обновляет таблицу, где хранятся данные о собственном капитале предприятия (действие 2). В это же время вторая транзакция делает попытку сначала обновить таблицу, где хранятся данные о собственном капитале предприятия (действие 1), а затем удалить 1000 акций со счета (действие 2).
Как видим, в результате мы получим взаимоблокировку, поскольку каждая таблица будет ожидать, пока другая не закончит работу с таблицей, к которой она хочет получить доступ. Если эту ситуацию оставить такой, как она есть, взаимоблокировка такого типа приведет к тому, что каждая из участвующих в ней транзакций будет ожидать неопределенное время, пока другая не снимет свою блокировку. К счастью, дескриптор таблиц типа InnoDB в MySQL снабжен интеллектом, достаточным для определения ситуаций взаимоблокировки. Если он обнаружит ситуацию наподобие вышеописанной, он разрешает ситуацию взаимоблокировки откатом одной из транзакций, участвующих в блокировке (и снятием их блокировок), таким образом разрешая другим транзакциям доработать до логического конца. Как и в предыдущем примере, клиент, транзакция которого была отменена, получает диагностическое сообщение об откате своей транзакции.