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

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

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

Блокировка WRITE:

Блокировки WRITE обычно имеют более высокий приоритет, чем блокировки READ, чтобы гарантировать, что обновления обрабатываются как можно быстрее. Это означает, что если одна сессия получает блокировку READ, а затем другая сессия запрашивает блокировку WRITE, последующие запросы на блокировку READ ожидают, пока сессия, запросившая блокировку WRITE, получит блокировку и не снимет её. (Исключение из этого правила может возникнуть для малых значений системной переменной max_write_lock_count; см. Раздел 10.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. См. Раздел 15.7.8.4, «Команда KILL».

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

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

Область действия блокировки, созданной командой LOCK TABLES, ограничена одним сервером MySQL. Она не совместима с NDB Cluster, поскольку у него нет способа принудительной реализации блокировки на уровне SQL для нескольких экземпляров mysqld. Вместо этого можно принудительно реализовать блокировку в приложении API. Дополнительную информацию см. в Разделе 25.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.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() для высокой скорости. См. Раздел 14.14, «Функции блокировки».

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