Для получения блокировок таблиц в текущей сессии используйте оператор LOCK TABLES, который получает блокировки метаданных (см. Раздел 8.11.4, «Блокировка метаданных»).

Доступны следующие типы блокировок:

Блокировка READ [LOCAL]:

Блокировка [LOW_PRIORITY] WRITE:

Блокировки WRITE обычно имеют более высокий приоритет, чем блокировки READ, чтобы обеспечить как можно более быстрое выполнение обновлений. Это означает, что если одна сессия получает блокировку READ, а затем другая сессия запрашивает блокировку WRITE, последующие запросы на блокировку READ ожидают, пока сессия, запросившая блокировку WRITE, получит и снимет блокировку. (Исключение из этого правила может произойти для малых значений системной переменной max_write_lock_count; см. Раздел 8.11.4, «Блокировка метаданных».)

Если оператор LOCK TABLES должен ждать из-за блокировок, удерживаемых другими сессиями на любых таблицах, он блокируется до тех пор, пока все блокировки не будут получены.

Сессия, требующая блокировок, должна получить все необходимые блокировки в одном операторе LOCK TABLES. Пока удерживаются полученные блокировки, сессия может обращаться только к заблокированным таблицам. Например, в следующей последовательности операторов возникает ошибка при попытке доступа к t2, так как она не была заблокирована в операторе LOCK TABLES:

mysql> LOCK TABLES t1 READ;
mysql> SELECT COUNT(*) FROM t1;
+----------+
| COUNT(*) |
+----------+
|        3 |
+----------+
mysql> SELECT COUNT(*) FROM t2;
ERROR 1100 (HY000): Table 't2' was not locked with LOCK TABLES

Таблицы в базе данных INFORMATION_SCHEMA являются исключением. К ним можно получить доступ без явного блокирования, даже когда сессия удерживает блокировки таблиц, полученные с помощью LOCK TABLES.

Вы не можете ссылаться на заблокированную таблицу несколько раз в одном запросе с тем же именем. Используйте псевдонимы вместо этого и получайте отдельную блокировку для таблицы и каждого псевдонима:

mysql> LOCK TABLE t WRITE, t AS t1 READ;
mysql> INSERT INTO t SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLES
mysql> INSERT INTO t SELECT * FROM t AS t1;

Ошибка возникает для первой INSERT, так как есть две ссылки на то же имя для заблокированной таблицы. Вторая INSERT выполняется успешно, так как ссылки на таблицу используют разные имена.

Если ваши операторы ссылаются на таблицу с помощью псевдонима, вы должны заблокировать таблицу, используя этот же псевдоним. Не работает блокировка таблицы без указания псевдонима:

mysql> LOCK TABLE t READ;
mysql> SELECT * FROM t AS myalias;
ERROR 1100: Table 'myalias' was not locked with LOCK TABLES

И наоборот, если вы блокируете таблицу с помощью псевдонима, вы должны ссылаться на неё в ваших операторах, используя этот же псевдоним:

mysql> LOCK TABLE t AS myalias READ;
mysql> SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLES
mysql> SELECT * FROM t AS myalias;

При освобождении блокировок таблиц, удерживаемых сеансом, все блокировки освобождаются одновременно. Сеанс может явно освободить свои блокировки или блокировки могут быть освобождены неявно в определенных условиях.

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

LOCK TABLES и UNLOCK TABLES взаимодействуют с использованием транзакций следующим образом:

Если вы явно блокируете таблицу с помощью LOCK TABLES, любые таблицы, используемые в триггерах, также неявно блокируются:

Предположим, что вы блокируете две таблицы, t1 и t2, используя этот оператор:

LOCK TABLES t1 WRITE, t2 READ;

Если у t1 или t2 есть триггеры, таблицы, используемые в триггерах, также блокируются. Предположим, что t1 имеет определенный триггер, как показано ниже:

CREATE TRIGGER t1_a_ins AFTER INSERT ON t1 FOR EACH ROW
BEGIN
  UPDATE t4 SET count = count+1
      WHERE id = NEW.id AND EXISTS (SELECT a FROM t3);
  INSERT INTO t2 VALUES(1, 2);
END;

Результат оператора LOCK TABLES состоит в том, что t1 и t2 заблокированы, так как они указаны в операторе, и t3 и t4 заблокированы, так как они используются в триггере:

Для безопасного завершения сессии, ожидающей блокировки таблицы, можно использовать KILL. См. Раздел 13.7.6.4, «Команда KILL».

Команды LOCK TABLES и UNLOCK TABLES не могут быть использованы внутри хранимых программ.

Таблицы в базе данных performance_schema не могут быть заблокированы с помощью LOCK TABLES, за исключением таблиц setup_xxx.

Область действия блокировки, созданной LOCK TABLES, ограничена одним сервером MySQL. Она не совместима с NDB Cluster, который не имеет возможности принудительного применения блокировки на уровне SQL через несколько экземпляров mysqld. Принудительную блокировку можно реализовать в приложении API. Дополнительную информацию см. в разделе 21.2.7.10, «Ограничения, связанные с несколькими узлами NDB Cluster».

Следующие команды запрещены, пока активна команда LOCK TABLES: CREATE TABLE, CREATE TABLE ... LIKE, CREATE VIEW, DROP VIEW, а также DDL-команды для хранимых функций, процедур и событий.

Для некоторых операций необходимо получить доступ к системным таблицам в базе данных mysql. Например, команда HELP требует содержимого таблиц справки на стороне сервера, а CONVERT_TZ() может потребовать чтения таблиц часовых поясов. Сервер неявно блокирует системные таблицы для чтения по мере необходимости, поэтому явное их блокирование не требуется. Эти таблицы обрабатываются как описано выше:

mysql.help_category
mysql.help_keyword
mysql.help_relation
mysql.help_topic
mysql.proc
mysql.time_zone
mysql.time_zone_leap_second
mysql.time_zone_name
mysql.time_zone_transition
mysql.time_zone_transition_type

Если вы хотите явно установить блокировку WRITE на любую из этих таблиц с помощью команды LOCK TABLES, то эта таблица должна быть единственной заблокированной; ни одна другая таблица не может быть заблокирована с помощью этой же команды.

Обычно блокировать таблицы не требуется, так как все отдельные команды UPDATE являются атомарными; ни одна другая сессия не может вмешаться в выполнение любой другой текущей SQL-команды. Однако есть несколько случаев, когда блокировка таблиц может быть выгодна:

Во многих случаях можно избежать использования LOCK TABLES с помощью относительных обновлений (UPDATE customer SET value=value+new_value) или функции LAST_INSERT_ID().

Также можно избежать блокировки таблиц в некоторых случаях с помощью функций консультирования блокировки на уровне пользователя GET_LOCK() и RELEASE_LOCK(). Эти блокировки сохраняются в хеш-таблице на сервере и реализуются с использованием pthread_mutex_lock() и pthread_mutex_unlock() для высокой скорости. См. раздел 12.14, «Функции блокировки».

Дополнительную информацию о политике блокировки см. в разделе 8.11.1, «Внутренние методы блокировки».