13.3.5.3. Блокирующие таблицу Ограничения и Условия

Можно безопасно использовать KILL завершать сеанс, который ожидает блокировки таблицы. См. Раздел 13.7.6.4,"KILL Синтаксис".

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

Таблицы в performance_schema база данных не может быть заблокирована с LOCK TABLES, кроме setup_xxx таблицы.

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

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

mysql.help_categorymysql.help_keywordmysql.help_relationmysql.help_topicmysql.procmysql.time_zonemysql.time_zone_leap_secondmysql.time_zone_namemysql.time_zone_transitionmysql.time_zone_transition_type

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

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

Если Вы собираетесь выполнить много операций на ряде MyISAM таблицы, это намного быстрее, чтобы заблокировать таблицы, которые Вы собираетесь использовать. Блокировка MyISAM таблицы ускоряют вставку, обновление, или удаление на них, потому что MySQL не сбрасывает ключевой кэш для заблокированных таблиц до UNLOCK TABLES вызывается. Обычно, ключевой кэш сбрасывается после каждого SQL-оператора.

Нижняя сторона к блокировке таблиц - то, что никакой сеанс не может обновить a READ- заблокированная таблица (включая тот, содержащий блокировку) и никакой сеанс, может получить доступ к a WRITE- заблокированная таблица кроме того, содержащего блокировку.
Если Вы используете таблицы для нетранзакционного механизма хранения, следует использовать LOCK TABLES если Вы хотите гарантировать, что никакой другой сеанс не изменяет таблицы между a SELECT и UPDATE. Пример, показанный здесь, требует LOCK TABLES выполниться безопасно:
```
LOCK TABLES trans READ, customer WRITE;SELECT SUM(value) FROM trans WHERE customer_id=some_id;UPDATE customer  SET total_value=sum_from_previous_statement  WHERE customer_id=some_id;UNLOCK TABLES;
```
Без LOCK TABLES, возможно, что другой сеанс мог бы вставить новую строку в trans таблица между выполнением SELECT и UPDATE операторы.

Можно избегать использования LOCK TABLES во многих случаях при использовании относительных обновлений (UPDATE customer SET value=value+new_value) или LAST_INSERT_ID() функция. См. Раздел 1.8.5.3, "Транзакция и Атомарные Различия в Работе".

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

См. Раздел 8.10.1, "Внутренние Методы Блокировки", для получения дополнительной информации о блокировке политики.