Синтаксис start transaction, commit и rollback

 

По умолчанию MySQL работает в режиме автоматического завершения транзакций (autocommit). Это означает, что как только выполняется оператор обновления данных, который модифицирует таблицу, MySQL тут же сохраняет изменения на диске.
Если вы работаете с таблицами, безопасными в отношении транзакций (такими как InnoDB и BDB), то режим автоматического завершения транзакций можно отключить сле­дующим оператором:

SET AUTOCOMMIT=0;

После отключения режима автоматического завершения транзакций вы должны ис­пользовать оператор COMMIT, чтобы сохранять изменения на диске, либо ROLLBACK, чтобы отменять изменения, выполненные с момента начала транзакции.
Если необходимо отключить режим автоматического завершения транзакций только для отдельной последовательности операторов, можете воспользоваться оператором START TRANSACTION:

START TRANSACTION;, @A:=SUM(salary) FROM tablel WHERE type=l;

UPDATE table2 SET summary=@A WHERE type=l;

COMMIT;

После START TRANSACTION режим автоматического завершения транзакций остается выключенным до явного завершения транзакции с помощью COMMIT или отката посред­ством ROLLBACK. Затем режим автоматического завершения возвращается в свое преды­дущее состояние.

Для некоторых операторов нельзя выполнить откат с помощью ROLLBACK. В их число входят операторы языка определения данных (Data Definition Language - DDL), которые создают и уничтожают базы данных, а также создают, удаляют и изменяют таблицы.

 

Синтаксис SAVEPOINTи ROLLBACK TO SAVEPOINT

SAVEPOINT идентификатор

ROLLBACK TO SAVEPOINT идентификатор

Начиная с версий MySQL 4.0.14 и 4.1.1, innoDB поддерживает SQL-операторы SAVEPOINT и ROLLBACK TO SAVEPOINT.
Оператор SAVEPOINT устанавливает именованную точку начала транзакции с именем идентификатор. Если текущая транзакция уже имеет точку сохранения с таким же име­нем, старая точка удаляется и устанавливается новая.
Оператор ROLLBACK TO SAVEPOINT откатывает транзакцию к именованной точке со­хранения. Модификации строк, которые выполнялись текущей транзакцией после этой точки, отменяются откатом, однако InnoDB не снимает блокировок строк, которые были установлены в памяти после точки сохранения. (Отметим, что для вновь вставленных строк информация о блокировке опирается на идентификатор транзакции, сохраненный в строке, блокировка не хранится в памяти отдельно. В этом случае блокировка строки снимается при отмене.) Точки сохранения, установленные в более поздние моменты, чем именованная точка, удаляются.

Если оператор возвращает следующую ошибку, это означает, что названная точка сохранения не существует:
ERROR 1181: Got error 153 during ROLLBACK
Все точки сохранения транзакций удаляются, если выполняется оператор COMMIT или ROLLBACK без указания имени точки сохранения.

 

Синтаксис LOCK TABLES и UNLOCK TABLES

 

LOCK TABLES имя_таблицы [AS псевдоним]

{READ [LOCAL] | LOW_PRIORITY] WRITE} [, имя_таблицы [AS псевдоним] {READ [LOCAL] | [LOW_PRIORITY] WRITE}]... UNLOCK TABLES

LOCK TABLES блокирует таблицы для текущего потока сервера.

UNLOCK TABLES снима­ет любые блокировки, удерживаемые текущим потоком. Все таблицы, заблокированные в текущем потоке, неявно разблокируются, когда поток выполняет другой оператор LOCK TABLES либо когда закрывается соединение с сервером. LOCK TABLES не является оператором, безопасным в отношении транзакций, и неявно заверша­ет транзакцию перед попыткой блокировать таблицы. Начиная с версии MySQL 4.0.2, для того, чтобы выполнять LOCK TABLES, необходимо иметь привилегию LOCK TABLES и привилегию для соответствующих таблиц. В MySQL 3.23 необходимо иметь привилегии, INSERT, DELETE и UPDATE для этих таблиц.
Основная причина применения LOCK TABLES - эмуляция транзакций или повышение скорости обновления таблиц. Ниже это объясняется более подробно.Если поток устанавливает блокировку по чтению (READ) на таблице, то этот поток (и все остальные) может только читать данные из таблицы. Если поток устанавливает бло­кировку записи (WRITE) таблицы, то лишь этот поток может читать и писать в таблицу. Доступ остальных нитей к таблице блокируется.
Разница между READ LOCAL и READ состоит в том, что READ LOCAL позволяет некон­фликтующим операторам INSERT (параллельным вставкам) выполняться, пока блокиров­ка удерживается. Однако это не может быть выполнено, если вы пытаетесь манипулиро­вать файлами базы данных извне MySQL в то время, пока удерживается блокировка. В случае применения LOCK TABLES необходимо блокировать все таблицы, которые используются в запросах. Если одна и та же таблица используется несколько раз в за­просе (через псевдонимы), вы должны получить блокировку на каждый псевдоним. Пока блокировка, полученная от LOCK TABLES, активна, вы не можете получить доступ ни к каким таблицам, которые не были блокированы этим оператором.
Если ваш запрос обращается к таблице через псевдоним, вы должны блокировать таблицу, используя тот же псевдоним. Блокировка таблицы не будет работать, если не указан псевдоним:

 

Синтаксис SET TRANSACTION

 

SET [GLOBAL|SESSION] TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }

Этот оператор устанавливает уровень изоляции следующей транзакции, глобально либо только для текущего сеанса.

Поведение SET TRANSACTION по умолчанию заключается в том, что он устанавливает уровень изоляции для следующей (еще не стартовавшей) транзакции. Если вы транзакций по умолчанию для всех новых соединений, которые будут установлены с этого момента. Существующие соединения не затрагиваются. Для выполнения этого оператора нужно иметь привилегию SUPER. Применение ключевого слова SESSION уста­навливает уровень изоляции по умолчанию всех будущих транзакций только для теку­щего сеанса.

 

Транзакционная модель InnoDB

 

Назначение транзакционной модели InnoDB заключается в том, чтобы совместить лучшие свойства многовариантной базы данных и традиционной двухфазной блокировки. Для таблиц InnoDB осуществляется блокировка на уровне строки и запросы по умолчанию запускаются как целостное считывание без блокировок, подобно тому, как это реализовано в Oracle. Хранение таблицы блокировок InnoDB организовано настолько экономично, что нет необходимости в расширении блокировки: обычно несколько пользователей могут блокировать любую строку или любой набор строк в базе данных, не занимая всю память, доступную для InnoDB.

В таблицах InnoDB все действия пользователей осуществляются при помощи транзакций. Если в MySQL используется режим автоматической фиксации, то для каждого оператора SQL будет создаваться отдельная транзакция. MySQL всегда открывает новое соединение с включенным режимом автоматической фиксации.

Если режим автоматической фиксации отключен при помощи SET AUTOCOMMIT = 0, то мы предполагаем, что у пользователя постоянно имеется открытая транзакция. Если он выполняет оператор SQL COMMIT или ROLLBACK, которые завершают текущую транзакцию, сразу же запускается новая транзакция. Оба упомянутых оператора снимают все блокировки InnoDB, которые были установлены во время выполнения текущей транзакции. Оператор COMMIT означает, что изменения, внесенные во время выполнения текущей транзакции, принимаются и становятся видимыми для других пользователей. Оператор ROLLBACK отменяет все изменения, внесенные текущей транзакцией.

Если в соединении установлено AUTOCOMMIT = 1, то пользователь, тем не менее, может использовать транзакции, начиная их с BEGIN и заканчивая при помощи COMMIT или ROLLBACK.

В терминах описания уровней изоляции транзакций (SQL-1992), InnoDB по умолчанию использует REPEATABLE READ. Начиная с версии 4.0.5, InnoDB предлагает все 4 уровня изоляции описанные в стандарте SQL-1992. Вы можете установить уровень изоляции по умолчанию для всех соединений в секции [mysqld] файла my.cnf:

 

transaction-isolation = {READ-UNCOMMITTED | READ-COMMITTED | REPEATABLE-READ | SERIALIZABLE}

Пользователь может изменить уровень изоляции для отдельно взятой сессии или нового соединения таким образом:

 

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}

Обратите внимания что названия уровней изоляции пишется без дефиса в SQL-выражении. Если вы указали ключевое слово GLOBAL в указанном выше выражении, оно будет определять уровень изоляции для новых соединений, но не будет иметь эффекта для старых соединений. Любой пользователь может изменить уровень изоляции для своей сессии, даже внутри самой транзакции. В версиях старше 3.23.50 SET TRANSACTION не оказывает эффекта на таблицы InnoDB. В версиях старше 4.0.5 вы можете использовать только REPEATABLE READ и SERIALIZABLE.

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

SELECT @@global.tx_isolation;

SELECT @@tx_isolation;

В блокировке уровня строки InnoDB использует так называемую блокировку следующего ключа. Это означает, что кроме индексных записей InnoDB может также блокирует "интервал" перед индексной записью для блокировки вставок другими пользователями непосредственно перед индексной записью. Блокировка следующего ключа означает блокировку, которая ставится на индексную запись и интервал перед ней. Блокировка интервала означает только блокировку интервала перед некоторыми индексными записями.

Подробное описание каждого уровня изоляции в InnoDB:

· READ UNCOMMITTED Также называется "грязным чтением": неблокирующиеся выборки (SELECT) выполняются таким образом, что мы не видим возможные ранние версии записи; таким образом они "несогласованно" читаются в этом уровне изоляции; в остальных случаях этот уровень работает также как и READ COMMITTED.

· READ COMMITTED Нечто похожее на уровень изоляции Oracle. Все выражения SELECT... FOR UPDATE и SELECT... LOCK IN SHARE MODE блокируют только индексные записи и не блокируют интервал перед ними. Поэтому они позволяют свободно добавлять новые записи после заблокированных. UPDATE и DELETE, которые используют уникальный индекс и уникальные условия поиска, блокируют только найденную индексную запись, и не блокируют интервал перед ней. Но в UPDATE и DELETE диапазонного типа в InnoDB должны установить блокировку следующего ключа или интервальную блокировку и блокировать добавления другими пользователями в интервал, покрытый диапазоном. Это необходимо, т.к. "фантомные строки" должны быть блокированы для успешной работы репликации и восстановления в MySQL. Согласованное чтение работает как и в Oracle: каждое согласованное чтение, даже внутри одной транзакции, устанавливает и читает свой собственный снимок.

· REPEATABLE READ Этот уровень изоляции используется в InnoDB по умолчанию. SELECT... FOR UPDATE, SELECT... LOCK IN SHARE MODE, UPDATE, и DELETE, которые используют уникальные индексы и уникальное условие поиска блокируют только найденную индексную запись и не блокируют интервал перед ней. В остальных случаях эта операция использует блокировку следующего ключа, блокирует диапазон индексов, просканированных блокировкой следующего ключа или интервальной, и блокирует новые добавления другими пользователями.

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

· SERIALIZABLE Этот уровень похож на предыдущий, но простые SELECT преобразовываются в SELECT... LOCK IN SHARE MODE.

 

Согласованное чтение

 

Согласованное чтение означает, что для того, чтобы предоставить запросу копию базы данных на текущий момент времени, используется многовариантность таблиц InnoDB. Для запроса доступны лишь те изменения, которые были внесены транзакциями, зафиксированными на этот момент времени, и не доступны изменения, сделанные незафиксированными или проведенными позже транзакциями. Исключением из данного правила могут стать только изменения, внесенные транзакцией, направляющей текущий запрос.

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

Согласованное чтение является режимом по умолчанию, в котором в InnoDB обрабатываются операторы SELECT при READ COMMITTED или REPEATABLE READ уровнях изоляции. При согласованном чтении не устанавливаются блокировки на таблицы, к которым обращается запрос, и, таким образом, остальные пользователи могут вносить изменения в эти таблицы одновременно с согласованным чтением таблиц.

 

Чтение с блокировкой

 

В некоторых случаях использовать согласованное чтение нецелесообразно. Приведем пример. Допустим, что необходимо добавить новую строку в таблицу CHILD, предварительно убедившись, что для нее имеется родительская строка в таблице PARENT.

Предположим, что для чтения таблицы PARENT было использовано согласованное чтение, и в таблице была обнаружена родительская строка. Можно ли теперь безопасно добавить дочернюю строку в таблицу CHILD? Нет, потому что в это время другой пользователь мог без вашего ведома удалить родительскую строку из таблицы PARENT.

В данной ситуации необходимо выполнить операцию SELECT в режиме блокировки, LOCK IN SHARE MODE.

SELECT * FROM PARENT WHERE NAME = 'Jones' LOCK IN SHARE MODE;

Выполнение чтения в режиме совместного использования (share mode) означает, что считываются самые новые доступные данные и производится блокировка строк, чтение которых осуществляется. Если последние данные принадлежат еще не зафиксированной транзакции, мы ждем, пока транзакция не будет зафиксирована. Блокировка в режиме совместного использования не позволяет другим пользователям обновить или удалить читаемую строку. После того, как указанный выше запрос вернет родительскую строку 'Jones', мы можем безопасно добавить дочернюю строку в таблицу CHILD и зафиксировать транзакцию. В этом примере показано, как использовать целостность ссылочных данных в своей программе.

Рассмотрим еще один пример. Пусть у нас есть поле целочисленного счетчика в таблице CHILD_CODES, которое мы используем для назначения уникального идентификатора каждой дочерней записи, добавляемой к таблице CHILD. Очевидно, что использование согласованного чтения или чтения в режиме совместного доступа для получения текущего значения счетчика не подходит, так как два пользователя базы данных могут получить одно и то же значение счетчика и создать дублирующиеся ключи при добавлении двух дочерних записей в таблицу.

Для этого случая возможны два способа произвести чтение и увеличить значение счетчика: (1) сначала обновить значение счетчика, увеличив его на 1, и только после этого прочитать его или (2) сначала прочитать счетчик в режиме блокировки FOR UPDATE, а после этого увеличить его значение:

SELECT COUNTER_FIELD FROM CHILD_CODES FOR UPDATE;

UPDATE CHILD_CODES SET COUNTER_FIELD = COUNTER_FIELD + 1;

Оператор SELECT... FOR UPDATE прочитает последние доступные данные с установкой отдельной блокировки на каждую считываемую строку. Таким образом, блокировка на строки устанавливается точно так же, как и в случае поиска по UPDATE.