Для получения блокировок таблиц в текущей сессии используйте утверждение 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, «Внутренние методы блокировки».