1.8.5.3. Транзакция и Атомарные Различия в Работе

MySQL Server (3.23-максимальная версия и все версии 4.0 и выше) поддерживает транзакции с InnoDB транзакционный механизм хранения. В MySQL 5.5 и, недавно создаваемое табличное использование InnoDB по умолчанию, как объяснено в Разделе 14.2.1.1,"InnoDB как Механизм Хранения MySQL Default". По умолчанию, InnoDB обеспечивает полное соответствие ACID; см. Раздел 14.2.8, "MySQL и Модель ACID" для способов, которыми можно скорректировать настройки, чтобы сбалансировать соответствие ACID с необработанной производительности. Для получения информации о InnoDB различия от стандартного SQL относительно обработки ошибок транзакции, см. Раздел 14.2.3.15,"InnoDB Обработка ошибок".

Нетранзакционные механизмы хранения в MySQL Server (такой как MyISAM) следуйте за различной парадигмой для целостности данных, вызванной "атомарные операции". MyISAM таблицы эффективно всегда работают в autocommit = 1 режим. Поскольку измененные данные пишутся диску один оператор за один раз, более трудно гарантировать непротиворечивость последовательности связанных операций DML, которые могли быть прерваны отчасти через. Таким образом этот режим является подходящим для рабочих нагрузок чтения главным образом. В транзакционных сроках, в то время как каждое определенное обновление работает, никакой другой пользователь не может вмешаться в него, никогда не может быть автоматического отката, и нет никаких грязных чтений. Однако, эти функции применяются к единственным операциям, не связанным обновлениям, которые успешно выполняются или перестали работать как модуль. Обходные решения такой как LOCK TABLES предел оператора параллельный доступ для записи к нетранзакционным таблицам.

Можно выбрать который парадигма использовать, даже для различных таблиц в пределах того же самого приложения: транзакционные функции надежности, объединенной с высокой производительностью, или атомарными операциями для некритического, данных чтения главным образом (например, на ведомых серверах репликации).

Транзакционные механизмы хранения такой как InnoDB предложите много существенных функций, чтобы поддерживать высокую надежность для тяжелых рабочих нагрузок чтения-записи. В результате у транзакционных таблиц могут быть более высокая память и требования к пространству на диске, и больше издержек ЦП. Модульная конструкция Сервера MySQL позволяет параллельному использованию различных механизмов хранения удовлетворить различным требованиям и поставить оптимальную производительность во всех ситуациях.

Обходные решения для Надежности с Нетранзакционными Таблицами

Но как делают Вы используете функции MySQL Server, чтобы поддержать целостность даже с нетранзакционным MyISAM таблицы, и как эти функции сравниваются с транзакционными механизмами хранения?

Если Ваши приложения пишутся в пути, который зависит от возможности вызвать ROLLBACK вместо COMMIT в критических ситуациях транзакции более удобны. Транзакции также гарантируют, что незаконченные обновления или действия повреждения не посвящают себя базе данных; серверу дают возможность сделать, автоматический откат и Ваша база данных сохраняются.

Если Вы используете нетранзакционные таблицы, следует разрешить потенциальные проблемы на уровне приложения включением проверок перед обновлениями и рабочими сценариями, которые проверяют базы данных на несогласованности и автоматически восстанавливают или предупреждают, если такая несогласованность происходит. Можно обычно фиксировать таблицы без потери целостности данных при использовании журнала MySQL или даже добавления одного дополнительного журнала.
Иногда, критические транзакционные обновления могут быть переписаны, чтобы быть атомарными. Многократные операции DML могут быть сделаны с LOCK TABLES или атомарные обновления, гарантируя, что нет никаких мертвых блокировок, ограничивая параллельный доступ для записи. Если Вы получаете a READ LOCAL блокировка (в противоположность блокировке записи) для таблицы, которая включает параллельным вставкам в конце таблицы, чтения, разрешается, как вставки другими клиентами. Недавно вставленные записи не быть замеченными клиентом, у которого есть блокировка чтения, пока она не выпускает блокировку. С INSERT DELAYED, можно записать, вставляет, которые входят в локальную очередь, пока блокировки не выпускаются, не имея клиент ожидают вставки, чтобы завершиться. См. Раздел 8.10.3, "Параллельные Вставки", и Раздел 13.2.5.2,"INSERT DELAYED Синтаксис".
Чтобы быть безопасными с MySQL Server, независимо от того, какие виды таблиц Вы используете, делают регулярные резервные копии и включали двоичный файл, регистрирующий. Всегда хорошо иметь резервные копии, независимо от которых системы баз данных Вы используете.

Следующее является некоторыми методами для того, чтобы работать с нетранзакционными таблицами:

Циклы, которые нуждаются в транзакциях обычно, могут кодироваться со справкой LOCK TABLES, и Вы не нуждаетесь в курсорах, чтобы обновить записи на лету.
Избегать использования ROLLBACK, можно использовать следующую стратегию:
1. Использовать LOCK TABLES чтобы заблокировать все таблицы, Вы хотите получить доступ.
2. Протестируйте условия, которые должны быть истиной прежде, чем выполнить обновление.
3. Обновление, если условия удовлетворяются.
4. Использовать UNLOCK TABLES выпускать Ваши блокировки.
Отметить

Это решение не обрабатывает ситуацию, когда кто-то уничтожает потоки в середине обновления. В этом случае все блокировки выпускаются, но некоторые из обновлений не могли быть выполнены.
Можно также использовать функции, чтобы обновить записи в единственной работе, используя следующие методы:
- Измените столбцы относительно их текущей стоимости. Это делает обновление корректным, даже если другой клиент изменил значения столбцов тем временем.
- Обновите только те столбцы, которые фактически изменились. Это - хорошая практика базы данных вообще.
Управляя уникальными идентификаторами, можно избежать операторов такой как LOCK TABLES или ROLLBACK при использовании AUTO_INCREMENT столбец и любой LAST_INSERT_ID() Функция SQL или mysql_insert_id() C API-функция. См. Раздел 12.14, "информационные Функции", и Раздел 21.8.7.37,"mysql_insert_id()".

Для ситуаций, которые требуют блокировки на уровне строки, использовать InnoDB таблицы. Иначе, с MyISAM таблицы, можно использовать столбец флага в таблице и сделать что-то как следующее:
```
UPDATE tbl_name SET row_flag=1 WHERE id=ID;
```
Возвраты MySQL 1 для числа строк, на которые влияют, если строка была найдена и row_flag не был 1 в исходной строке. Можно думать об этом как если бы MySQL Server, измененный предыдущий оператор на:
```
UPDATE tbl_name SET row_flag=1 WHERE id=ID AND row_flag <> 1;
```